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
