[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAGXu5jKCZmZSJHK-EFunNtbqbxBT1KsLE31VygapwgZX9XmFAg@mail.gmail.com>
Date: Thu, 8 Sep 2016 08:50:39 -0700
From: Kees Cook <keescook@...omium.org>
To: Catalin Marinas <catalin.marinas@....com>
Cc: "kernel-hardening@...ts.openwall.com" <kernel-hardening@...ts.openwall.com>, Will Deacon <will.deacon@....com>,
AKASHI Takahiro <takahiro.akashi@...aro.org>, Julien Grall <julien.grall@....com>,
James Morse <james.morse@....com>,
"linux-arm-kernel@...ts.infradead.org" <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH v2 0/7] arm64: Privileged Access Never using TTBR0_EL1 switching
On Thu, Sep 8, 2016 at 5:51 AM, Catalin Marinas <catalin.marinas@....com> wrote:
> On Wed, Sep 07, 2016 at 04:20:55PM -0700, Kees Cook wrote:
>> On Fri, Sep 2, 2016 at 8:02 AM, Catalin Marinas <catalin.marinas@....com> wrote:
>> > This is the second version of the arm64 PAN emulation by disabling
>> > TTBR0_EL1 accesses. The major change from v1 is the use of a thread_info
>> > member to store the real TTBR0_EL1 value. The advantage is slightly
>> > simpler assembler macros for uaccess_enable with the downside that
>> > switch_mm() must always update the saved ttbr0 even if there is no mm
>> > switch.
>>
>> Is arm64 thread_info attached to the kernel stack? (i.e. is this
>> introducing a valuable target for stack-based attacks?)
>
> Currently yes, thread_info is on the kernel stack. At some point we'll
> decouple it in a similar way to what x86 are doing/planning.
Okay, cool. As long as this is on the horizon, that's cool. :)
> If thread_info on the stack can be corrupted, ttbr0 is not our only
> worry but I agree it adds to the existing ones (addr_limit, task_struct
> pointer).
>
> That said, I don't have a strong preference for thread_info vs per-CPU
> variable for the shadow TTBR0. The latter feels a bit more natural to me
> since TTBR0 can be seen as a CPU state (that's what I did in v1).
> However, using thread_info saves us couple of instructions in the asm
> code for uaccess_enable.
I would opt for the safer (in per-CPU area), but I have clear biases.
;) Getting this emulation at all closes a huge exploitation method, so
on balance, the new exposure (which as you say is already not the only
target on the stack) is worth it. :)
Thanks!
-Kees
--
Kees Cook
Nexus 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.
