[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAGXu5j++0LgDEv=m1yQb4hB57MQ2MYVCpeex9TFTRmQpNYhNsQ@mail.gmail.com>
Date: Wed, 7 Sep 2016 16:20:55 -0700
From: Kees Cook <keescook@...omium.org>
To: Catalin Marinas <catalin.marinas@....com>
Cc: "linux-arm-kernel@...ts.infradead.org" <linux-arm-kernel@...ts.infradead.org>,
"kernel-hardening@...ts.openwall.com" <kernel-hardening@...ts.openwall.com>,
AKASHI Takahiro <takahiro.akashi@...aro.org>, Will Deacon <will.deacon@....com>,
James Morse <james.morse@....com>, Julien Grall <julien.grall@....com>
Subject: Re: [PATCH v2 0/7] arm64: Privileged Access Never using TTBR0_EL1 switching
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?)
-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.
