On Wed, Sep 14, 2016 at 11:30:05AM +0100, Ard Biesheuvel wrote:

On 14 September 2016 at 11:27, Mark Rutland [off-list ref] wrote:

quoted

On Wed, Sep 14, 2016 at 11:13:33AM +0100, Ard Biesheuvel wrote:

quoted

On 13 September 2016 at 18:46, Catalin Marinas [off-list ref] wrote:

quoted

This is the third version of the arm64 PAN emulation using TTBR0_EL1
switching.

quoted

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.