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] [thread-next>] [day] [month] [year] [list]

Message-ID: <CALCETrX5BeOKJ2VCgzzs2My_nBp7N8_=F4Oc5kPuB7w+NTrk+g@mail.gmail.com>
Date:   Thu, 15 Jun 2017 14:44:38 -0700
From:   Andy Lutomirski <luto@...nel.org>
To:     Paolo Bonzini <pbonzini@...hat.com>
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 Tue, May 30, 2017 at 9:05 AM, Paolo Bonzini <pbonzini@...hat.com> wrote:
>
>
> On 30/05/2017 17:58, Roman Penyaev wrote:
>> Indeed, what is left is eventually take it from SS.RPL. J.
>
> Ahah! :)  But I only suggested that in specific cases.
>
>> But jokes aside,  with your last patch you seems fixed a race problem
>> when "CS.RPL is not equal to the CPL in the few instructions between
>> setting CR0.PE and reloading CS".
>
> Yes, exactly.  The symptom was a crash (triple fault) when you kept
> interrupting with "info cpus" a guest that repeatedly went to protected
> mode and back to real mode.
>
>> 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!

I wonder if we can sweep that particular problem under the rug by
saying that, as a KVM guest, you can't program STAR.RPL != 3?  Or
would that require us to set an intercept that we don't want to set?

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.  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?

--Andy