linux-kernel - Re: [PATCH v2 4/4] KVM: x86: get CPL from SS.DPL

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CALeycy9s_NFDC+p6d8W_xYXPjXE4PFWJGz6kwvJi9EQ1Kqg_Vw@mail.gmail.com>
Date:	Tue, 27 May 2014 00:22:00 -0500
From:	Wei Huang <huangwei.virt@...il.com>
To:	Paolo Bonzini <pbonzini@...hat.com>
Cc:	kvm@...r.kernel.org, linux-kernel@...r.kernel.org,
	"J. Kiszka" <jan.kiszka@...mens.com>, gleb@...nel.org,
	Avi Kivity <avi.kivity@...il.com>
Subject: Re: [PATCH v2 4/4] KVM: x86: get CPL from SS.DPL

>>
>>
>> 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 linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/