On Oct 25, 2014 12:57 PM, "Nadav Amit" <nadav.a...@gmail.com> wrote: > > > > On Oct 24, 2014, at 20:53, Andy Lutomirski <l...@amacapital.net> wrote: > > > > On 10/24/2014 08:07 AM, Paolo Bonzini wrote: > >> From: Nadav Amit <na...@cs.technion.ac.il> > >> > >> Before changing rip (during jmp, call, ret, etc.) the target should be > >> asserted > >> to be canonical one, as real CPUs do. During sysret, both target rsp and > >> rip > >> should be canonical. If any of these values is noncanonical, a #GP > >> exception > >> should occur. The exception to this rule are syscall and sysenter > >> instructions > >> in which the assigned rip is checked during the assignment to the relevant > >> MSRs. > > > > Careful here. AMD CPUs (IIUC) send #PF (or maybe #GP) from CPL3 instead > > of #GP from CPL0 on sysret to a non-canonical address. That behavior is > > *far* better than the Intel behavior, and it may be important. > I wasn’t aware of this discrepancy, and it is really not written clearly in > AMD manual (I have to take your word). It is possible AMD decided to inject > #GP from CPL3 (#PF makes no sense). > > Anyhow, I think it is much harder to emulate AMD’s behaviour on Intel. > Theoretically, the easy way would be for the host to set a non-canonical > guest RIP/RSP and inject #GP, but Intel CPUs don’t allow the host to do so. > Instead, the host needs to emulate the entire exception injection. This is > very hard and error-prone process due to the variety of scenarios > (interrupt/task-gate on the IDT, #DF, nested-exceptions, etc.) >
Hmm. Fair enough. I guess emulating AMD's behavior just on AMD is complicated. > > > > > If an OS relies on that behavior on AMD CPUs, and guest ring 3 can force > > guest ring 0 to do an emulated sysret to a non-canonical address, than > > the guest ring3 code can own the guest ring0 code. > > > > —Andy > > Sysexit (I mistakenly wrote sysret on the description), out of all the > control transfer instructions, seems the hardest to exploit, since it must be > executed in CPL0. > Remember that this bug does not result in host crashing, but in guest > crashing: If guest userspace is able to cause KVM to emulate a jump > instruction to a non-canonical address, it can crash the entire guest (by > preventing VM-entry from succeeding). To use sysexit for such exploit, the > guest userspace needs also to somehow fool the guest kernel into returning > into non-canonical RIP. True. I don't know about sysexit, but there's a long and storied history of sysret vulnerabilities based on this Intel erratum^Wclever design decision. As a practical matter, is sysexit ever emulated on Intel CPUs? If not, this may be irrelevant. --Andy > > Nadav -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
