So far unprivileged guest callers running in ring 3 can issue, e.g., MMU
hypercalls. Normally, such callers cannot provide any hand-crafted MMU
command structure as it has to be passed by its physical address, but
they can still crash the guest kernel by passing random addresses.
To close the
Jan Kiszka wrote:
So far unprivileged guest callers running in ring 3 can issue, e.g., MMU
hypercalls. Normally, such callers cannot provide any hand-crafted MMU
command structure as it has to be passed by its physical address, but
they can still crash the guest kernel by passing random
On 08/03/2009 04:47 PM, Jan Kiszka wrote:
So far unprivileged guest callers running in ring 3 can issue, e.g., MMU
hypercalls. Normally, such callers cannot provide any hand-crafted MMU
command structure as it has to be passed by its physical address, but
they can still crash the guest kernel by
On 08/03/2009 05:04 PM, Anthony Liguori wrote:
Actually, VT mandates that vmcalls can only be done from CPL=0.
That's exactly how I misremembered it. However the docs say
IF not in VMX operation
THEN #UD;
ELSIF in VMX non-root operation
THEN VM exit;
ELSIF (RFLAGS.VM = 1) OR
Avi Kivity wrote:
On 08/03/2009 05:04 PM, Anthony Liguori wrote:
Actually, VT mandates that vmcalls can only be done from CPL=0.
That's exactly how I misremembered it. However the docs say
IF not in VMX operation
THEN #UD;
ELSIF in VMX non-root operation
THEN VM exit;
ELSIF
On 08/03/2009 06:04 PM, Anthony Liguori wrote:
So CPL 0 is only enforced on VMCALL from the hypervisor, not the
guest (tip: don't ask what VMCALL in the hypervisor means).
Ah, it's used to call SMM peer mode... awesome :-)
Now you'll never be able to sleep at night. Well I did try to warn
