kernel-hardening - Re: [PATCH v3 0/7] arm64: Privileged Access Never using TTBR0

Follow @Openwall on Twitter for new release announcements and other news

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20160914103632.GD14330@leverpostej>
Date: Wed, 14 Sep 2016 11:36:46 +0100
From: Mark Rutland <mark.rutland@....com>
To: Ard Biesheuvel <ard.biesheuvel@...aro.org>
Cc: Catalin Marinas <catalin.marinas@....com>,
	"linux-arm-kernel@...ts.infradead.org" <linux-arm-kernel@...ts.infradead.org>,
	Will Deacon <will.deacon@....com>,
	James Morse <james.morse@....com>,
	Kees Cook <keescook@...omium.org>,
	AKASHI Takahiro <takahiro.akashi@...aro.org>,
	kernel-hardening@...ts.openwall.com
Subject: Re: [PATCH v3 0/7] arm64: Privileged Access Never using TTBR0_EL1
 switching

On Wed, Sep 14, 2016 at 11:30:05AM +0100, Ard Biesheuvel wrote:
> On 14 September 2016 at 11:27, Mark Rutland <mark.rutland@....com> wrote:
> > On Wed, Sep 14, 2016 at 11:13:33AM +0100, Ard Biesheuvel wrote:
> >> On 13 September 2016 at 18:46, Catalin Marinas <catalin.marinas@....com> wrote:
> >> > This is the third version of the arm64 PAN emulation using TTBR0_EL1
> >> > switching.
> >
> >> Given that every __get_user() call now incurs the PAN switch overhead,
> >> I wonder if it would be worth it to stash the real TTBR0_EL1 value in,
> >> e.g., TPIDRRO_EL0 rather than load it from memory each time. We'd have
> >> to reload the real value of TPIDRRO_EL0 at kernel exit every time, but
> >> only for compat tasks, and not nearly as often, obviously.
> >
> > FWIW, my plan for vmap'd stacks involves clobbering TPIDRRO_EL0 early
> > upon kernel entry to reliably detect/handle stack overflow (as we need
> > to free up GPR to detect overflow, and we need to detect that before we
> > try to store to the stack).
> >
> > For non-compat tasks we must restore zero, so either way we'll end up
> > with a load (to determine compat-ness or to load the precise value).
> 
> Are you saying that with vmapped stacks, we'll end up clobbering it
> (and thus restoring it) anyway when entering the kernel, and so we
> could use it for free afterwards while running in the kernel,
> potentially for the real value of TTBR0_EL1?

Yes, assuming that we end up following my current plan for how to
implement that.

Thanks,
Mark.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.