[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAGXu5jKp0J_6+upysRXbc1Khjzr20DrdM6As8ZS=QcccN7jpfg@mail.gmail.com>
Date: Mon, 24 Jul 2017 20:34:31 -0700
From: Kees Cook <keescook@...omium.org>
To: Alexander Popov <alex.popov@...ux.com>
Cc: Laura Abbott <labbott@...hat.com>, Mark Rutland <mark.rutland@....com>,
"kernel-hardening@...ts.openwall.com" <kernel-hardening@...ts.openwall.com>,
Ard Biesheuvel <ard.biesheuvel@...aro.org>, Tycho Andersen <tycho@...ker.com>,
PaX Team <pageexec@...email.hu>
Subject: Re: [RFC][PATCH 2/2] arm64: Clear the stack
On Mon, Jul 24, 2017 at 1:19 AM, Alexander Popov <alex.popov@...ux.com> wrote:
> On 22.07.2017 03:23, Laura Abbott wrote:
>> On 07/21/2017 09:56 AM, Alexander Popov wrote:
>>> So let's keep it not to break CONFIG_SCHED_STACK_END_CHECK.
>>
>> That makes sense, good find! I wonder if CONFIG_SCHED_STACK_END_CHECK
>> should go on the list of hardening options and/or if we can enhance
>> it somehow?
>
> Do you mean this list?
> http://www.kernsec.org/wiki/index.php/Kernel_Self_Protection_Project/Recommended_Settings
>
>> I'm not sure why it requires two words though since the
>> poison only seems to be 32-bits?
>
> On x86_64 end_of_stack() returns the pointer to unsigned long, so we need at
> least 8 bytes to avoid breaking CONFIG_SCHED_STACK_END_CHECK. Don't know about 8
> more bytes.
Seems like this should be a random value like the per-frame stack
canary, but it looks like a relatively cheap check. It's probably not
in the cache, though, since most stack operations should be pretty far
from the end of the stack...
-Kees
--
Kees Cook
Pixel Security
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
