On 2024-05-13 13:36-0700, Sean Christopherson wrote: > Hmm, a slightly crazy idea (ok, maybe wildly crazy) would be to support mapping > all of guest_memfd into kernel address space, but as USER=1 mappings. I.e. don't > require a carve-out from userspace, but do require CLAC/STAC when access guest > memory from the kernel. I think/hope that would provide the speculative execution > mitigation properties you're looking for? This is interesting. I'm hesitant to rely on SMAP since it can be enforced too late by the microarchitecture. But Canella, et al. [1] did say in 2019 that the kernel->user access route seemed to be free of any "Meltdown" effects. LASS sounds like it will be even stronger, though it's not clear to me from Intel's programming reference that speculative scenarios are in scope [2]. AMD does list SMAP specifically as a feature that can control speculation [3]. I don't see an equivalent read-access control on ARM. It has PXN for execute. Read access can probably also be controlled? But I think for the non-CoCo case we should favor solutions that are less dependent on hardware-specific protections. Derek [1] https://www.usenix.org/system/files/sec19-canella.pdf [2] https://cdrdv2.intel.com/v1/dl/getContent/671368 [3] https://www.amd.com/content/dam/amd/en/documents/epyc-technical-docs/tuning-guides/software-techniques-for-managing-speculation.pdf
