On 23/06/2025 1:41 pm, Kirill A. Shutemov wrote: > On Fri, Jun 20, 2025 at 04:21:38PM -0700, Dave Hansen wrote: >> On 6/20/25 16:08, Andrew Cooper wrote: >>>> But, the resulting code is wonky. It needs to do something more like this: >>>> >>>> if ((error_code & (X86_PF_WRITE | X86_PF_USER)) != X86_PF_USER) >>>> return false; >>>> >>>> if (error_code & X86_PF_INSTR)) >>>> return __emulate_vsyscall(regs, address); >>> To do this, LASS needs a proper interlink against NX || SMEP. >>> >>> If neither NX nor SMEP are active, the CPU does not report X86_PF_INSTR, >>> meaning that fetches are reported as plain reads. >> Interesting point. >> >> I think the easiest way to do this is just make a cpuid_deps[] entry for >> LASS and NX. If there's a CPU where LASS is available but where NX isn't >> available, we have much bigger problems on our hands. > I am not sure what I suppose to do here. > > Sohil pointed out that with LASS we get #GP on vsyscall, not #PF and PFEC > is not relevant for LASS. Correct. That was my mistake originally. > > So, IIUC, that's dependency of vsyscall PF on NX. Do we want to disable > vsyscall on boot if NX is not available? > > BTW, why do we even support !NX on X86_64? Is there such HW? Yes. Early P4 steppings had no NX at all. ~Andrew
