Messages in this thread | | | From | "Edgecombe, Rick P" <> | Subject | Re: [PATCH v3 00/12] Enable Linear Address Space Separation support | Date | Fri, 4 Aug 2023 23:52:58 +0000 |
| |
On Mon, 2023-07-31 at 15:36 -0700, Rick Edgecombe wrote: > 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.
Maybe get_kernel_gp_address() could be enhanced to give hints for some of those cases like it does for non-canonical addresses?
Separately, I think there is a tiny userspace visible change with this. If userspace tries to access the kernel half of the cannonical address space they will get a segfault. It seems previously the signal would have REG_TRAPNO as 14 (X86_TRAP_PF) in this case, but with LASS it will be 13 (X86_TRAP_GP).
I did a quick search and couldn't find any applications that seemed to be relying on this behavior (not surprising). Some are looking for REG_TRAPNO as 14, but none appeared to be relying on accesses to kernel memory so I guess this should be ok. Still, it is probably appropriate to call out the change and CC linux-api.
It makes me wonder if it should match for LASS and not LASS going forward though. Like maybe always do X86_TRAP_GP for user->kernel accesses instead of having it vary by whether LASS is used? Since there isn't enough information to do REG_TRAPNO X86_TRAP_PF when LASS is used.
| |