linux-kernel - Re: [RFC] KVM: SVM: do not drop VMCB CPL to 0 if SS is not present

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: Windows password security audit tool. GUI, reports in PDF.

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

Date:   Fri, 16 Jun 2017 18:40:18 +0200
From:   Paolo Bonzini <pbonzini@...hat.com>
To:     Andy Lutomirski <luto@...nel.org>
Cc:     Roman Penyaev <roman.penyaev@...fitbricks.com>,
        Mikhail Sennikovskii <mikhail.sennikovskii@...fitbricks.com>,
        Gleb Natapov <gleb@...nel.org>, kvm list <kvm@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [RFC] KVM: SVM: do not drop VMCB CPL to 0 if SS is not present



On 15/06/2017 23:44, Andy Lutomirski wrote:
> On Tue, May 30, 2017 at 9:05 AM, Paolo Bonzini <pbonzini@...hat.com> wrote:
>> On 30/05/2017 17:58, Roman Penyaev wrote:
>>> We will have CPL in var->dpl, and it seems ok.  All we need is not
>>> to lose it on the way kernel->userspace->kernel.
>>
>> You're right.  So what do you think of the other suggestion (svm.c
>> doesn't clear attributes for unusable registers, QEMU only clears P for
>> unusable registers)?
> 
> AMD CPUs really allow setting RPL in MSR_*STAR to something other than
> 3 and then blindly copy the result to SS.DPL when SYSRET happens?
> Ugh!

For AMD, "a data-segment-descriptor DPL field is ignored in 64-bit mode"
(4.8.2).  This is unlike Intel, where SS.DPL is the CPL.

After SYSRET, CPL is always 3, even if CS.RPL != 3.

> Alternatively, is there ever a case where CPL == 3, SS.DPL != 3 and
> non-root code can observe the fact that SS.DPL != 3?  If not, maybe
> KVM could just change SS.DPL to 3 whenever it reads out SS if CPL ==
> 3.  Then CPL really could live in the SS state even on SVM.

Currently that's almost what happens, except the "migration" of the CPL
field into SS.DPL only happens when going through QEMU.

> In other
> words, if a weird guest forces SS.RPL ! = 3 by programming garbage
> into *STAR and doing SYSRET, could that guest tell the difference if
> we non-deterministically changed SS.DPL back to 3 out from under it?
> Or is there some nasty case in which SS.DPL == 0, CPL == 3, SS is
> valid and you're in compat mode, and you expect stack access to fail
> because SS.DPL < CPL?

No, any case where STAR is programmed with RPL != 3 is garbage.

Paolo