On 15/06/2017 23:44, Andy Lutomirski wrote: > On Tue, May 30, 2017 at 9:05 AM, Paolo Bonzini <pbonzini@xxxxxxxxxx> 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
