On Thu, Feb 14, 2019 at 6:31 AM Singh, Brijesh <brijesh.singh@xxxxxxx> wrote: > > > > On 2/14/19 6:26 AM, Paolo Bonzini wrote: > > On 13/02/19 20:02, Singh, Brijesh wrote: > >>> Ok so that's pretty messed up. Is this fixed with newer microcode, and > >>> how widespread is this silicon? I'm tempted to just blacklist SMAP on > >>> the affected steppings. > >> > >> This errata is applicable to Family 17h model 00_0fh only, and it is > >> definitely planned to fix in the upcoming CPUs. For now, we just need to > >> workaround for the Fam 17h_00_0Fh. > > > > So it's on all steppings; no microcode fix. :( > > Unfortunately yes :( > > > > >> I am not sure about blacklist SMAP all together, for non SEV its > >> very easy to workaround. For SEV case, I am just trying to say that > >> we will *not* workaround (it does not mean that its not possible) > >> > >>> Would it work to retry the instruction with CR4.SMAP=0 and EFLAGS.TF=1, > >>> and set CR4.SMAP back to 1 in the #DB handler? > >> > >> Theoretically we should be able to do this to workaround. But since > >> the errata is not wide spread hence I am not sure about going to > >> this path. Also there are not many apps doing MMIO from userspace > >> hence I thought its okay to not workaround for the SEV guest. > >> > >> Having said so, if we find the actual need to workaround then we can > >> go to that path. > > > > If it's not too hard, having the workaround would be nice(r). > > > > For now I am inclined to go with what we have. Will submit v2 > with fixes. > > Theoretically we can use the single stepping with CR4.SMAP=0. SEV allows the hypervisor to override the guest OS's CR4.SMAP setting?!? That seems counter-intuitive, given SEV's intended use. Doesn't this potentially give a ring-3 agent in the guest an avenue to privilege escalation through collusion with the hypervisor?
