Support for Intel's LASS

Posted Jan 13, 2023 18:09 UTC (Fri) by hansendc (subscriber, #7363)
In reply to: Support for Intel's LASS by dezgeg
Parent article: Support for Intel's LASS

Yeah, it's theoretically possible to emulate vsyscalls that were thwarted by LASS. But, the current emulation leverages page fault exceptions (#PF). Those are nice because page faults set a control register (CR2) to the address that faulted. That makes it dirt simple to tell if an access to the vsyscall page caused the fault: "if (is_vsyscall_vaddr(address))".

LASS produces general protection faults (#GP). Unfortunately, #GP's don't set CR2 and the CPU doesn't give great information about why the fault occurred. It's quite possible to go fetch the instruction that faulted, decode it, and figure out that it was accessing the vsyscall page. The kernel does exactly that for some #GP's. But, it's kinda icky, and is best avoided.

But, if someone *REALLY* cares deeply, please do speak up.

Support for Intel's LASS

Posted Jan 13, 2023 21:59 UTC (Fri) by pbonzini (subscriber, #60935) [Link] (1 responses)

In the case of a vsyscall, wouldn't the #GP have a saved instruction pointer in the vsyscall page (LASS documentation says "the fault is reported on the branch target, not the branch instruction")?

Such an RIP would only be reachable with a call or jmp instruction, and if it was a call then the return address would already be on the stack. All you'd have to do would be invoke the system call, replace RIP with a word popped off the stack and go back to userspace.

Not that it's a good idea. :)

Support for Intel's LASS

Posted Jan 17, 2023 16:31 UTC (Tue) by luto (guest, #39314) [Link]

I assume what’s going on is that the CPU will fault on any attempt to set RIP to an address in the wrong half of the address space.

Intel has an unfortunate history of designing CPUs that validate RIP when setting RIP instead of when using RIP. This results in rather unfortunate bugs^Woutcomes when doing creative things like putting a SYSCALL instruction at the very top of the lower half of the address space. The SYSCALL works fine and sets RCX (the saved pointer to the subsequent instruction) to RIP+2, which is noncanonical. This is fine (from a very narrowly focused perspective) because RCX isn’t RIP. A subsequent SYSRET will try to set RIP to the saved value and fault. This is fine because it’s how the CPU works (which is an excuse for almost anything), but it’s barely documented. The fault will cause an exception frame to be written to the user RSP, because that’s how SYSRET works (see above about excuses). The result is privilege escalation.

AMD generally seems more sensible in this regard.