| Message ID | 20230224194652.1990604-1-dave@stgolabs.net |
|---|---|
| Headers | show |
| Series | cxl: Background cmds and device sanitation | expand |
+Cc Dave (sorry). On Fri, 24 Feb 2023, Davidlohr Bueso wrote: >Hello, > >This series adds support for the rest of the security related cxl operations >which are not strictly dependent on PMEM. > >Patch 1 adds the required background cmd handling bits (polling and irq). >This is really the main motivation of the series as there are various >features that will need this regardless of sanitation. > >Patch 2 adds a new sysfs 'security/state' file, which shows "disabled" if >no security features are available - which is more intuitive than no showing >it. > >Patch 3 adds a way to check if the device is actively used by tracking regions >with target the memdevice to sanitize. I realize this might not be what is >desired and wanted to get the expectations for this. This is more of a RFC >patch. > >Patches 4-7 add the Sanitation and Secure Erase support, per CXL3.0 specs. > >These changes have been tested with both the mock device as well as with qemu[0,1]. > >Changes from v2 (https://lore.kernel.org/linux-cxl/20221206011501.464916-1-dave@stgolabs.net/): >- Redid the bacground cmd handling to use a syncronous approach instead. >- Added cxl_memdev_active_region() to check if the memdevice is being used > (actively decoding any HPA ranges). >- Create a new security sysfs directory with a 'state' file which is always visible. >- The sysfs files' to trigger the security commands is only visible if > cpu_cache_has_invalidate_memregion(). >- Added a sanitize test for the mock device. > >Please consider for v6.4. > >Thanks! > >[0]: https://github.com/davidlohr/qemu/commit/64a93a5b824b59d3b547f06f7fbb1269fb4790ce >[1]: https://lore.kernel.org/linux-cxl/20230224194443.1990440-1-dave@stgolabs.net > >Davidlohr Bueso (7): > cxl/mbox: Add background cmd handling machinery > cxl/security: Add security state sysfs ABI > cxl/region: Add cxl_memdev_active_region() > cxl/mem: Support Sanitation > cxl/test: Add "Sanitize" opcode support > cxl/mem: Support Secure Erase > cxl/test: Add "Secure Erase" opcode support > > Documentation/ABI/testing/sysfs-bus-cxl | 34 +++++++ > drivers/cxl/core/mbox.c | 117 +++++++++++++++++++++++ > drivers/cxl/core/memdev.c | 119 ++++++++++++++++++++++++ > drivers/cxl/core/region.c | 33 ++++++- > drivers/cxl/cxl.h | 13 +++ > drivers/cxl/cxlmem.h | 14 +++ > drivers/cxl/pci.c | 100 +++++++++++++++++++- > tools/testing/cxl/test/mem.c | 52 +++++++++++ > 8 files changed, 476 insertions(+), 6 deletions(-) > >-- >2.39.2 >
On Fri, 24 Feb 2023, Davidlohr Bueso wrote: >Hello, > >This series adds support for the rest of the security related cxl operations >which are not strictly dependent on PMEM. > >Patch 1 adds the required background cmd handling bits (polling and irq). >This is really the main motivation of the series as there are various >features that will need this regardless of sanitation. > >Patch 2 adds a new sysfs 'security/state' file, which shows "disabled" if >no security features are available - which is more intuitive than no showing >it. > >Patch 3 adds a way to check if the device is actively used by tracking regions >with target the memdevice to sanitize. I realize this might not be what is >desired and wanted to get the expectations for this. This is more of a RFC >patch. > >Patches 4-7 add the Sanitation and Secure Erase support, per CXL3.0 specs. > >These changes have been tested with both the mock device as well as with qemu[0,1]. > >Changes from v2 (https://lore.kernel.org/linux-cxl/20221206011501.464916-1-dave@stgolabs.net/): >- Redid the bacground cmd handling to use a syncronous approach instead. >- Added cxl_memdev_active_region() to check if the memdevice is being used > (actively decoding any HPA ranges). >- Create a new security sysfs directory with a 'state' file which is always visible. >- The sysfs files' to trigger the security commands is only visible if > cpu_cache_has_invalidate_memregion(). >- Added a sanitize test for the mock device. > >Please consider for v6.4. Hi Dan, ping? I would like to see were we stand with this series and hopefully still time for 6.4 material - but that's not important. The open points which imo would best be answered before attempting a v4 based on the current input: - Are you ok with the approach in patch 1? - Are you ok with security directory always showing at least the state file? As Dave mentions this differs somewhat with nfit, but for that matter so does the whole security semantics (this is now a directory vs a single, multiplexed file). - Regarding ensuring the device is not actively decoding, would Alison/Fan's suggestion to use commit_end/hdm_end instead of my hacky patch 3 be feasible? Or did you have something else in mind? Thanks, Davidlohr