On Tue, Jun 27, 2023, Sean Christopherson wrote:
> > + /*
> > + * An access is a supervisor-mode access if CPL < 3 or if it implicitly
> > + * accesses a system data structure. For implicit accesses to system
> > + * data structure, the processor acts as if RFLAGS.AC is clear.
> > + */
> > + if (access & PFERR_IMPLICIT_ACCESS) {
>
> Please don't use PFERR_IMPLICIT_ACCESS, just extend the new flags. This is
> obviously not coming from a page fault. PFERR_IMPLICIT_ACCESS really shouldn't
> exist, but at least there was reasonable justification for adding it (changing
> all of the paths that lead to permission_fault() would have require a massive
> overhaul).
>
> ***HOWEVER***
>
> I think the entire approach of hooking __linearize() may be a mistake, and LASS
> should instead be implemented in a wrapper of ->gva_to_gpa(). The two calls to
> __linearize() that are escaped with SKIPLASS are escaped *because* they don't
> actually access memory (branch targets and INVLPG), and so if LASS is enforced
> only when ->gva_to_gpa() is invoked, all of these new flags go away because the
> cases that ignore LASS are naturally handled.
>
> That should also make it unnecessary to add one-off checks since e.g. kvm_handle_invpcid()
> will hit kvm_read_guest_virt() and thus ->gva_to_gpa(), i.e. we won't end up playing
> an ongoing game of whack-a-mole.
Drat, that won't work, at least not without quite a few more changes.
1. kvm_{read,write,fetch}_guest_virt() are effectively defined to work with a
fully resolve linear address, i.e. callers assume failure means #PF
2. Similar to (1), segment information isn't available, i.e. KVM wouldn't know
when to inject #SS instead of #GP
And IIUC, LASS violations are higher priority than instruction specific alignment
checks, e.g. on CMPXCHG16B.
And looking at LAM, that untagging needs to be done before the canonical checks,
which means that we'll need at least X86EMUL_F_INVLPG.
So my idea of shoving this into a ->gva_to_gpa() wrapper won't work well. Bummer.
