>> >> >> Is this specified anywhere in SDM as a requirement for x86 OS? If so, >> maybe provide a pointer to support this. > > > In the case of the Intel manuals, it mentions in several places that > SS.DPL=CPL. All the mentions are in the VMX sections of the manual, though > I've found non-Intel material saying that system-management mode also used > SS.DPL as the CPL: > > * "SS.DPL corresponds to the logical processor’s current privilege level > (CPL)" (footnote in 26.3.1.5 Checks on Guest Non-Register State). > > * "SS.DPL is always loaded from the SS access-rights field. This will be the > current privilege level (CPL) after the VM entry completes" (26.3.2.2 > Loading Guest Segment Registers and Descriptor-Table Registers) > > * "VMX-critical state [...] consists of the following: (1) SS.DPL (the > current privilege level);" (34.14.1 Default Treatment of SMI delivery [in > VMX mode]). > > Instead, AMD says that "the SS segment base, limit and attributes are not > modified" by sysret. It almost looks as if AMD processors never use SS.DPL; > almost because searching "SS.attr" in the AMD manuals shows that the > processor does write to SS.attr sometimes. In the SVM documentation, it > says "The processor reads the current privilege level from the CPL field in > the VMCB, not from SS.DPL. However, SS.DPL should match the CPL field" and > sneakily leaves out what happens if they do not match... My guess is that SS.DPL==CPL will fail during VMRUN. This can be quickly tested by slightly tweaking VMCB content of a regular VM. > > >>> case of SYSRET on AMD processors, which sets SS.DPL=SS.RPL from the >>> value in the STAR MSR, but force CPL=3 (Intel instead forces >>> SS.DPL=SS.RPL=CPL=3). >> >> >> Thinking out loud here... Should we force SYSRET SS.RPL to be 3 when >> VM updates STAR MSR? Following the same thought, does it make sense to >> check (and force) SS.DPL==3 when STAR MSR is being updated. Will >> forcing SYSRET SS.DPL=3 break any OS? I think any reasonable OS would >> probably sets SS.RPL=SS.DPL=3. > > > Yes, I wondered in fact how much the AMD behavior is a bug. > > We could emulate Intel behavior on AMD by shadowing the STAR MSR; the guest > reads the intended SS.DPL and SS.RPL but the processor actually always runs > with bits 49-48 of STAR set to 3. This should ensure that CPL=SS.DPL always > even on AMD. I'm not sure if this has any worth though... When SS.DPL != CPL for a VM, the worst case without STAR emulation proposed above is the crash of the VM, which it deserves. So I think we are fine here. > > Paolo > > -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
