Re: CXL device sanitation and pmem security questions

[Dave Jiang <dave.jiang@intel.com>]

On 7/7/2022 12:05 PM, Davidlohr Bueso wrote:
> Hello,
>
> While going through the Sanitize and Pmem Data-at-rest security parts
> of the 2.0 spec, I was wondering if the community had any ideas about
> how this would look when implemented. I am not a security person, but
> this is how I'm interpreting this stuff.
>
> 1. Sanitize (8.2.9.5.5) which includes volatile and persistent regions.
>
> Have a /sys/bus/cxl/devices/memX/erase write-only file which upon 0 or 1
> values will do sanitize or secure erase, respectively. In case of the
> sanitize command, if this is a background operation, the echo/write will
> wait until complete. Alternatively we could just rely on the next 
> sanitize
> command to just return media disabled error if the previous one is still
> running and not worry.
>
> While this command is running with media disabled state, what happens
> when successfully complete? Does the state change and loads/stores have
> effect again? Does the driver need to do anything here? There is little
> info about this. Similarly, the secure erase is done entirely by hw (both
> having no in/out payloads).
>
> Both commands note that prior to using them, "any security applied to
> the user data areas of the device shall be disabled" (or unlocked for
> secure erase). Is this referring only to the PMEM part (below)? Iow,
> get security capabilities would need to be consulted (for the
> CONFIG_CXL_PMEM cases)? Or would this check be done by hardware instead
> and return error if the security requirements are not met?
>
> The cxl cmd would look like:
>
> #> cxl sanitize mem0 (alternatively pass -E for secure erase).
>
> 2. Pmem Security (8.2.9.5.6)
>
> Will this be along the same lines as what nvdimm does[1]? and have a
> /sys/bus/cxl/devices/memX/security file that multiplexes the
> different security features. Alternatively I guess the above could
> also be done within the same security file, instead of having two.
>
> The cxl cmd would look like, based on what ndctl(1) does; as well
> as the -m master option:
>
> #> cxl load-keys <params>
> #> cxl setup-passphrase mem0
> #> cxl update-passphrase mem0
> #> cxl remove-passphrase mem0
> #> cxl unlock mem0
> #> cxl sanitize -PE mem0 (passphrase secure erase)
> #> cxl freeze-security mem0
>
> [1] 
> https://www.kernel.org/doc/html/latest/driver-api/nvdimm/security.html


Hi Davidlohr, I'm actually looking at the implementation of this right 
now. I think initially if we provide a CXL secruity_ops to nvdimm 
similar to EFI NFIT provider, we should theoretically be able to do all 
the security bits through ndctl via nvdimm. I think I'll probably have 
better answers to your questions once I get some code going and see how 
things work.

>
> Thanks,
> Davidlohr