Davidlohr Bueso wrote: > On Wed, 30 Nov 2022, Dan Williams wrote: > > >Davidlohr Bueso wrote: > >> On Wed, 30 Nov 2022, Dave Jiang wrote: > >> > >> >Bypass cpu_cache_invalidate_memregion() and checks when doing testing > >> >using CONFIG_NVDIMM_SECURITY_TEST flag. The bypass allows testing on > >> >QEMU where cpu_cache_has_invalidate_memregion() fails. Usage of > >> >cpu_cache_invalidate_memregion() is not needed for cxl_test security > >> >testing. > >> > >> We'll also want something similar for the non-pmem specific security > >> bits > > > >Wait, you expect someone is going to build a device *with* security > >commands but *without* pmem? In the volatile case the device can just > >secure erase itself without user intervention every time power is > >removed, no need for explicit user action to trigger that. So the > >data-at-rest security argument goes away with a pure volatile device, > >no? > > Well the spec explicitly states that sanitation can be done to volatile > capacity devices, which makes me think the use case for this would not > require rebooting.
It does, but Linux supports memory sharing across multiple tenants today without secure erase. So I think the specification may have been getting ahead of itself about how useful that is as a concept, at least in the near term. In the long term, when memory may be shared outside of the system I think the kernel will have an interest in santizing that memory before it leaves the local system control, but for that there's the "Sanitize on Release" facility for DCD regions. You are right though, I was under the mistaken impression that CXL Secure Erase behaved like PMEM [1], and only erased the persistent media, not the volatile, but the spec says it erases everything user accessible. That's going to need to make it as violent as CXL Sanitize from the perspective of what needs to be taken offline before the operation, similar to PMEM Overwrite. However, the cache management for Sanitize, Secure Erase, and Unlock can all be unified under the same cxl_region_invalidate_memregion() proposal. Basically any time the DPA contents are changed behind the kernel's back either "in-place" by a security operation, or a "remap" event of assigning different DPA, any associated regions get marked CXL_REGION_F_INCOHERENT. Then the region driver can handle cache management centrally if the given device gets reactivated. That also has the nice property of deferring wbinvd violence until the last possible moment where the cache incoherence can actually spill over into a data corruption scenario. [1]: https://pmem.io/documents/IntelOptanePMem_DSM_Interface-V3.0.pdf
