CXL device sanitation and pmem security questions

CXL device sanitation and pmem security questions

[Davidlohr Bueso]

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

Thanks,
Davidlohr

Re: CXL device sanitation and pmem security questions

[Davidlohr Bueso]

On Thu, 07 Jul 2022, Davidlohr Bueso wrote:
>Iow, get security capabilities would need to be consulted (for the
>CONFIG_CXL_PMEM cases)?

s/capabilities/state.

Re: CXL device sanitation and pmem security questions

[Dave Jiang]

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

Re: CXL device sanitation and pmem security questions

[Davidlohr Bueso]

On Thu, 07 Jul 2022, Dave Jiang wrote:

>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.

I assume you mean only the pmem security part #2, right? This makes sense,
but of course for sanitize this would not work, which might also need to
consult security state regardless of security_ops::get_flags().

Thanks,
Davidlohr

Re: CXL device sanitation and pmem security questions

[Dave Jiang]

On 7/8/2022 10:24 AM, Davidlohr Bueso wrote:
> On Thu, 07 Jul 2022, Dave Jiang wrote:
>
>> 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.
>
> I assume you mean only the pmem security part #2, right? This makes 
> sense,
> but of course for sanitize this would not work, which might also need to
> consult security state regardless of security_ops::get_flags().
Right. I haven't gotten that far yet. :)
>
> Thanks,
> Davidlohr