| Message ID | 20230726051940.3570-2-dave@stgolabs.net |
|---|---|
| State | Accepted |
| Commit | 0fcde5989e8a54b2a155d8bcea21a7f99abb50f9 |
| Headers | show |
| Series | cxl/memdev: Make sanitize interfaces conditionally available | expand |
On 7/25/23 22:19, Davidlohr Bueso wrote: > Be more detailed about the CPU cache management situation. The same > goes for both sanitize and secure erase. > > Signed-off-by: Davidlohr Bueso <dave@stgolabs.net> Reviewed-by: Dave Jiang <dave.jiang@intel.com> > --- > Documentation/ABI/testing/sysfs-bus-cxl | 13 +++++++++++-- > 1 file changed, 11 insertions(+), 2 deletions(-) > > diff --git a/Documentation/ABI/testing/sysfs-bus-cxl b/Documentation/ABI/testing/sysfs-bus-cxl > index 6350dd82b9a9..c4c4acb1f3b3 100644 > --- a/Documentation/ABI/testing/sysfs-bus-cxl > +++ b/Documentation/ABI/testing/sysfs-bus-cxl > @@ -82,7 +82,11 @@ Description: > whether it resides in persistent capacity, volatile capacity, > or the LSA, is made permanently unavailable by whatever means > is appropriate for the media type. This functionality requires > - the device to be not be actively decoding any HPA ranges. > + the device to be disabled, that is, not actively decoding any > + HPA ranges. This permits avoiding explicit global CPU cache > + management, relying instead for it to be done when a region > + transitions between software programmed and hardware committed > + states. > > > What /sys/bus/cxl/devices/memX/security/erase > @@ -92,7 +96,12 @@ Contact: linux-cxl@vger.kernel.org > Description: > (WO) Write a boolean 'true' string value to this attribute to > secure erase user data by changing the media encryption keys for > - all user data areas of the device. > + all user data areas of the device. This functionality requires > + the device to be disabled, that is, not actively decoding any > + HPA ranges. This permits avoiding explicit global CPU cache > + management, relying instead for it to be done when a region > + transitions between software programmed and hardware committed > + states. > > > What: /sys/bus/cxl/devices/memX/firmware/
On Tue, 25 Jul 2023 22:19:38 -0700 Davidlohr Bueso <dave@stgolabs.net> wrote: > Be more detailed about the CPU cache management situation. The same > goes for both sanitize and secure erase. > > Signed-off-by: Davidlohr Bueso <dave@stgolabs.net> > --- > Documentation/ABI/testing/sysfs-bus-cxl | 13 +++++++++++-- > 1 file changed, 11 insertions(+), 2 deletions(-) > > diff --git a/Documentation/ABI/testing/sysfs-bus-cxl b/Documentation/ABI/testing/sysfs-bus-cxl > index 6350dd82b9a9..c4c4acb1f3b3 100644 > --- a/Documentation/ABI/testing/sysfs-bus-cxl > +++ b/Documentation/ABI/testing/sysfs-bus-cxl > @@ -82,7 +82,11 @@ Description: > whether it resides in persistent capacity, volatile capacity, > or the LSA, is made permanently unavailable by whatever means > is appropriate for the media type. This functionality requires > - the device to be not be actively decoding any HPA ranges. > + the device to be disabled, that is, not actively decoding any > + HPA ranges. This permits avoiding explicit global CPU cache > + management, relying instead for it to be done when a region > + transitions between software programmed and hardware committed > + states. That worries me a bit. Sounds like we are leaving a possible attack vector after a user will assume that all data is definitely gone and their secrets secure. I'm not sure what the attack would be, but I'd be happier if we didn't forgo the cache evictions. This is not exactly a fast path at any time. However I though region tear down (and resulting HDM decoder disables) were followed by a flush anyway so there should be nothing there... > > > What /sys/bus/cxl/devices/memX/security/erase > @@ -92,7 +96,12 @@ Contact: linux-cxl@vger.kernel.org > Description: > (WO) Write a boolean 'true' string value to this attribute to > secure erase user data by changing the media encryption keys for > - all user data areas of the device. > + all user data areas of the device. This functionality requires > + the device to be disabled, that is, not actively decoding any > + HPA ranges. This permits avoiding explicit global CPU cache > + management, relying instead for it to be done when a region > + transitions between software programmed and hardware committed > + states. > > > What: /sys/bus/cxl/devices/memX/firmware/
On Fri, 04 Aug 2023, Jonathan Cameron wrote: >On Tue, 25 Jul 2023 22:19:38 -0700 >Davidlohr Bueso <dave@stgolabs.net> wrote: > >> Be more detailed about the CPU cache management situation. The same >> goes for both sanitize and secure erase. >> >> Signed-off-by: Davidlohr Bueso <dave@stgolabs.net> >> --- >> Documentation/ABI/testing/sysfs-bus-cxl | 13 +++++++++++-- >> 1 file changed, 11 insertions(+), 2 deletions(-) >> >> diff --git a/Documentation/ABI/testing/sysfs-bus-cxl b/Documentation/ABI/testing/sysfs-bus-cxl >> index 6350dd82b9a9..c4c4acb1f3b3 100644 >> --- a/Documentation/ABI/testing/sysfs-bus-cxl >> +++ b/Documentation/ABI/testing/sysfs-bus-cxl >> @@ -82,7 +82,11 @@ Description: >> whether it resides in persistent capacity, volatile capacity, >> or the LSA, is made permanently unavailable by whatever means >> is appropriate for the media type. This functionality requires >> - the device to be not be actively decoding any HPA ranges. >> + the device to be disabled, that is, not actively decoding any >> + HPA ranges. This permits avoiding explicit global CPU cache >> + management, relying instead for it to be done when a region >> + transitions between software programmed and hardware committed >> + states. > >That worries me a bit. Sounds like we are leaving a possible attack vector >after a user will assume that all data is definitely gone and their secrets secure. > >I'm not sure what the attack would be, but I'd be happier if we didn't forgo >the cache evictions. This is not exactly a fast path at any time. >However I though region tear down (and resulting HDM decoder disables) were followed >by a flush anyway so there should be nothing there... I had similar concerns, but ultimately could not come up with a potential attack scenario by not doing the flushing explicitly, which is before+after the operation, per the spec. https://lore.kernel.org/linux-cxl/6422888b688fd_21a8294a3@dwillia2-xfh.jf.intel.com.notmuch/ The main motivation for avoiding these calls is not really that this is a fast path, but it's that the global CPU flushing affects system-wide. That said, it's hard to argue on defaulting on the safe side and just doing the flushes - exactly because of reasons we don't know until too late. Dan? Thanks, Davidlohr
diff --git a/Documentation/ABI/testing/sysfs-bus-cxl b/Documentation/ABI/testing/sysfs-bus-cxl index 6350dd82b9a9..c4c4acb1f3b3 100644 --- a/Documentation/ABI/testing/sysfs-bus-cxl +++ b/Documentation/ABI/testing/sysfs-bus-cxl @@ -82,7 +82,11 @@ Description: whether it resides in persistent capacity, volatile capacity, or the LSA, is made permanently unavailable by whatever means is appropriate for the media type. This functionality requires - the device to be not be actively decoding any HPA ranges. + the device to be disabled, that is, not actively decoding any + HPA ranges. This permits avoiding explicit global CPU cache + management, relying instead for it to be done when a region + transitions between software programmed and hardware committed + states. What /sys/bus/cxl/devices/memX/security/erase @@ -92,7 +96,12 @@ Contact: linux-cxl@vger.kernel.org Description: (WO) Write a boolean 'true' string value to this attribute to secure erase user data by changing the media encryption keys for - all user data areas of the device. + all user data areas of the device. This functionality requires + the device to be disabled, that is, not actively decoding any + HPA ranges. This permits avoiding explicit global CPU cache + management, relying instead for it to be done when a region + transitions between software programmed and hardware committed + states. What: /sys/bus/cxl/devices/memX/firmware/
Be more detailed about the CPU cache management situation. The same goes for both sanitize and secure erase. Signed-off-by: Davidlohr Bueso <dave@stgolabs.net> --- Documentation/ABI/testing/sysfs-bus-cxl | 13 +++++++++++-- 1 file changed, 11 insertions(+), 2 deletions(-)