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

[Andy Lutomirski]

On Tue, May 30, 2017 at 9:05 AM, Paolo Bonzini <pbonzini@xxxxxxxxxx> 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