> On 16 Jul 2019, at 23:54, Sean Christopherson <sean.j.christopherson@xxxxxxxxx> wrote: > > On Tue, Jul 16, 2019 at 08:27:12PM +0000, Singh, Brijesh wrote: >> >> On 7/16/19 3:09 PM, Liran Alon wrote: >>>> >>>> We are discussing reserved NPF so we need to be at CPL3. >>> >>> I don’t see the connection between a reserved #NPF and the need to be at >>> CPL3. A vCPU can execute at CPL<3 a page that is mapped user-accessible in >>> guest page-tables in case CR4.SMEP=0 and then instruction will execute >>> successfully and can dereference a page that is mapped in NPT using an >>> entry with a reserved bit set. Thus, reserved #NPF will be raised while >>> vCPU is at CPL<3 and DecodeAssist microcode will still raise SMAP violation >>> as CR4.SMAP=1 and microcode perform data-fetch with CPL<3. This leading >>> exactly to Errata condition as far as I understand. >>> >> >> Yes, vCPU at CPL<3 can raise the SMAP violation. When SMEP is disabled, >> the guest kernel never should be executing from code in user-mode pages, >> that'd be insecure. So I am not sure if kernel code can cause this >> errata. > > From KVM's perspective, it's not a question of what is *likely* to happen > so much as it's a question of what *can* happen. Architecturally there is > nothing that prevents CPL<3 code from encountering the SMAP fault. Exactly. :) I will submit a v2 patch which also clarifies the details we understood in this email thread. Thanks, -Liran
