Re: [PATCH v3 00/12] Enable Linear Address Space Separation support

[Edgecombe, Rick P]

On Fri, 2023-06-09 at 21:36 +0300, Alexander Shishkin wrote:


What do NULL pointer de-references look like with LASS enabled? They
will be a #GP instead of a #PF, right? Currently the kernel prints out
several types of helpful messages:
 - "BUG: kernel NULL pointer dereference, address: %lx"
 - "BUG: unable to handle page fault for address: %px
 - "unable to execute userspace code (SMEP?) (uid: %d)"
 - etc

These will go away I guess, and you will get a more opaque "general
protection fault" message?

Assuming that is all right, I don't know if it might be worth tweaking
that #GP message, so people aren't confused when debugging. Something
that explains to turn off LASS to get more debugging info.

> Kernel accesses usually only happen to the kernel address space.
> However, there
> are valid reasons for kernel to access memory in the user half. For
> these cases
> (such as text poking and EFI runtime accesses), the kernel can
> temporarily
> suspend the enforcement of LASS by toggling SMAP (Supervisor Mode
> Access
> Prevention) using the stac()/clac() instructions.

CET introduces this unusual instruction called WRUSS. It allows you to
make user memory accesses while executing in the kernel. Because of
this special property, the CET shadow stack patches don't toggle
stac/clac while executing this instruction. So I think LASS will need
it to behave more like a normal userspace access from the kernel.
Shadow stack is not upstream yet, so just something to keep in mind for
the future.

Also, what is this series based on? I wasn't able to apply it.