NVMe write protection support

NVMe write protection support

[Gilles Buloz]

Dear developers,
In case an NVMe module has a write protection feature, what is the best  method for the NVMe to tell the kernel it is write protected (if any),  and how the kernel should handle a write to such a module ?
As computer manufacturers, we had a request from some customers to have the NVMe module fully write protected (fpr safety). So we asked our NVMe manufacturer partner to add thiss feature to their NVMe. But the problem is that if a write is done to this module while it is write protected, the kernel treats it as "critical medium error" (giving something like this in the dmesg : blk_update_request: critical medium error, dev nvme0n1, sector 977537456 op 0x1:(WRITE) flags 0x800 phys_seg
 2 prio class 0).
OK, no write should be attempted if the write protection is enabled, but this critical medium error is maybe too much because the disk is actually not damaged and read is still possible.
For SATA devices I see that we have a message like that in dmesg : "sd 6:0:0:0: [sdb] Write Protect is off", but nothing like this for NVMe. So maybe the write protection is not supported/expected for NVMe devices ?
Thanks

Re: NVMe write protection support

[Chao Leng]

On 2022/8/1 16:36, Gilles Buloz wrote:
> Dear developers,
> In case an NVMe module has a write protection feature, what is the best  method for the NVMe to tell the kernel it is write protected (if any),  and how the kernel should handle a write to such a module ?
Suggest: set the NSATTR of namespace to 1 when identify namespace.
> As computer manufacturers, we had a request from some customers to have the NVMe module fully write protected (fpr safety). So we asked our NVMe manufacturer partner to add thiss feature to their NVMe. But the problem is that if a write is done to this module while it is write protected, the kernel treats it as "critical medium error" (giving something like this in the dmesg : blk_update_request: critical medium error, dev nvme0n1, sector 977537456 op 0x1:(WRITE) flags 0x800 phys_seg
>   2 prio class 0).
> OK, no write should be attempted if the write protection is enabled, but this critical medium error is maybe too much because the disk is actually not damaged and read is still possible.
> For SATA devices I see that we have a message like that in dmesg : "sd 6:0:0:0: [sdb] Write Protect is off", but nothing like this for NVMe. So maybe the write protection is not supported/expected for NVMe devices ?
> Thanks
> .
> 

Re: NVMe write protection support

[Gilles BULOZ]

Thanks Chao for your suggestion : "Suggest: set the NSATTR of namespace to 1 when identify namespace."
Also thanks to Andrey Kuzmin for his private reply : "It sounds like the kernel nvme subsystem is either ignoring or misinterpreting 
the status code returned by the controller in the write completion. Per spec, an attempt to write to a write-protected namespace 
must be declined with 'Namespace is Write Protected' status code (see Nvme Command Set Spec. Fig. 67 for details) which, apparently, 
isn't critical wrt the device itself."
I'll check all this with our NVMe manufacturer

Le 01/08/2022 à 12:01, Chao Leng a écrit :
>
> On 2022/8/1 16:36, Gilles Buloz wrote:
>> Dear developers,
>> In case an NVMe module has a write protection feature, what is the best  method for the NVMe to tell the kernel it is write 
>> protected (if any),  and how the kernel should handle a write to such a module ?
> Suggest: set the NSATTR of namespace to 1 when identify namespace.
>> As computer manufacturers, we had a request from some customers to have the NVMe module fully write protected (fpr safety). So we 
>> asked our NVMe manufacturer partner to add thiss feature to their NVMe. But the problem is that if a write is done to this module 
>> while it is write protected, the kernel treats it as "critical medium error" (giving something like this in the dmesg : 
>> blk_update_request: critical medium error, dev nvme0n1, sector 977537456 op 0x1:(WRITE) flags 0x800 phys_seg
>>   2 prio class 0).
>> OK, no write should be attempted if the write protection is enabled, but this critical medium error is maybe too much because the 
>> disk is actually not damaged and read is still possible.
>> For SATA devices I see that we have a message like that in dmesg : "sd 6:0:0:0: [sdb] Write Protect is off", but nothing like 
>> this for NVMe. So maybe the write protection is not supported/expected for NVMe devices ?
>> Thanks
>> .
>>
> .

Re: NVMe write protection support

[Keith Busch]

On Mon, Aug 01, 2022 at 02:41:45PM +0200, Gilles BULOZ wrote:
> Thanks Chao for your suggestion : "Suggest: set the NSATTR of namespace to 1 when identify namespace."
> Also thanks to Andrey Kuzmin for his private reply : "It sounds like the
> kernel nvme subsystem is either ignoring or misinterpreting the status code
> returned by the controller in the write completion. Per spec, an attempt to
> write to a write-protected namespace must be declined with 'Namespace is
> Write Protected' status code (see Nvme Command Set Spec. Fig. 67 for
> details) which, apparently, isn't critical wrt the device itself."
> I'll check all this with our NVMe manufacturer

The driver doesn't do anything special with the "Namespace is Write Protected",
status so that should get a generic IO Error if the device was returning that.

The driver will currently return a Medium error block status if we get a
"Attempted Write to Read Only Range" nvme status, though. Maybe that would make
more sense as a target error.

 
> Le 01/08/2022 à 12:01, Chao Leng a écrit :
> > 
> > On 2022/8/1 16:36, Gilles Buloz wrote:
> > > Dear developers,
> > > In case an NVMe module has a write protection feature, what is the
> > > best  method for the NVMe to tell the kernel it is write protected
> > > (if any),  and how the kernel should handle a write to such a module
> > > ?
> > Suggest: set the NSATTR of namespace to 1 when identify namespace.
> > > As computer manufacturers, we had a request from some customers to
> > > have the NVMe module fully write protected (fpr safety). So we asked
> > > our NVMe manufacturer partner to add thiss feature to their NVMe.
> > > But the problem is that if a write is done to this module while it
> > > is write protected, the kernel treats it as "critical medium error"
> > > (giving something like this in the dmesg : blk_update_request:
> > > critical medium error, dev nvme0n1, sector 977537456 op 0x1:(WRITE)
> > > flags 0x800 phys_seg
> > >   2 prio class 0).
> > > OK, no write should be attempted if the write protection is enabled,
> > > but this critical medium error is maybe too much because the disk is
> > > actually not damaged and read is still possible.
> > > For SATA devices I see that we have a message like that in dmesg :
> > > "sd 6:0:0:0: [sdb] Write Protect is off", but nothing like this for
> > > NVMe. So maybe the write protection is not supported/expected for
> > > NVMe devices ?
> > > Thanks
> > > .
> > > 
> > .
> 
> 

Re: NVMe write protection support

[Christoph Hellwig]

On Mon, Aug 01, 2022 at 08:36:12AM +0000, Gilles Buloz wrote:
> Dear developers,
> In case an NVMe module has a write protection feature,

Do you mean the "Namespace Write Protection Config", Feature Identifier
84h?  In that case you need to set bit 0 in the NSATTR field in the
Identify Namespace data structure(s) and the kernel will mark the
namespace read only.

If you mean something else, please clarify.

RE: NVMe write protection support

[Gilles Buloz]

Sorry Christoph, I'm completely newbie in NVMe and don't know what "Namespace Write Protection Config" means.
What I mean is that all the NVMe content seen by the user is write protected.
Our NVMe manufacturer partner has dedicated a pin of the module for global write protection. If the pin is high it is not possible to change even a single byte of the data stored by the user in the NVMe storage.
But if we enable this protection and attempt a write (we should not), we get a "critical medium error" which seems a bit brutal for a disk that is still valid but just write protected. So I would like to make sure the NVMe manufacturer has used the right method/status to report this write protection, and if possible get a less fatal error feedback.
Thanks 

> De : Christoph Hellwig <hch@infradead.org>
> Envoyé : lundi 1 août 2022 20:34
> À : Gilles Buloz <Gilles.Buloz@kontron.com>
> Cc : linux-nvme@lists.infradead.org <linux-nvme@lists.infradead.org>
> Objet : Re: NVMe write protection support 
 > 
> On Mon, Aug 01, 2022 at 08:36:12AM +0000, Gilles Buloz wrote:
> > Dear developers,
> > In case an NVMe module has a write protection feature,
> 
> Do you mean the "Namespace Write Protection Config", Feature Identifier
> 84h?  In that case you need to set bit 0 in the NSATTR field in the Identify
> Namespace data structure(s) and the kernel will mark the namespace read only.
> 
> If you mean something else, please clarify.

Re: NVMe write protection support

[Christoph Hellwig]

On Tue, Aug 02, 2022 at 09:20:02AM +0000, Gilles Buloz wrote:
> Sorry Christoph, I'm completely newbie in NVMe and don't know what "Namespace Write Protection Config" means.

Take a look at
https://nvmexpress.org/wp-content/uploads/NVM-Express-Base-Specification-2.0b-2021.12.18-Ratified.pdf
and search for this term.

> What I mean is that all the NVMe content seen by the user is write protected.

And that is what this feature is abut.

> Our NVMe manufacturer partner has dedicated a pin of the module for global write protection.

There is no concept of a 'module' in NVMe.

> But if we enable this protection and attempt a write (we should not), we get a "critical medium error" which seems a bit brutal for a disk that is still valid but just write protected. So I would like to make sure the NVMe manufacturer has used the right method/status to report this write protection, and if possible get a less fatal error feedback.

It seems like your manufacturer needs to read the NVMe spec and
implement the correct features.

RE: NVMe write protection support

[Gilles Buloz]

>On Sat, Aug 06, 2022 at 10:35:00 AM +0100, Christoph Hellwig wrote:
> 
>>On Tue, Aug 02, 2022 at 09:20:02AM +0000, Gilles Buloz wrote:
>> Sorry Christoph, I'm completely newbie in NVMe and don't know what "Namespace Write Protection Config" means.
>
>Take a look at
>https://nvmexpress.org/wp-content/uploads/NVM-Express-Base-Specification-2.0b-2021.12.18-Ratified.pdf
>and search for this term.

Thank you for the specs.

>> What I mean is that all the NVMe content seen by the user is write protected.
>
>And that is what this feature is abut.
>
>> Our NVMe manufacturer partner has dedicated a pin of the module for global write protection.
>
>There is no concept of a 'module' in NVMe.

In fact this is a M.2 module : a M.2 PCIe SSD one. A M.2 GND pin has been reused for WP with a pull-up on module, so that if the module is plugged into a standard M.2 socket this pin is connected to GND and the module is not protected. And in a socket providing WP on this pin, the write protection can be enabled by setting the pin high or unconnected.

>> But if we enable this protection and attempt a write (we should not), we get a "critical medium error" which seems a bit brutal for a disk that is still valid but just write protected. So I would like to make sure the NVMe manufacturer has used the right method/status to report this write protection, and if possible get a less fatal error feedback.
>
>It seems like your manufacturer needs to read the NVMe spec and implement the correct features.

Yes, that's why I requested some tips from experts like you to be sure.
And with the features implemented correctly, is a the case of a write to a protected module already handled/expected by the kernel ? and what message the kernel is expected to report in dmesg ?

Re: NVMe write protection support

[Jonathan Derrick]

On 8/25/2022 2:26 AM, Gilles Buloz wrote:
>> On Sat, Aug 06, 2022 at 10:35:00 AM +0100, Christoph Hellwig wrote:
>>   
>>> On Tue, Aug 02, 2022 at 09:20:02AM +0000, Gilles Buloz wrote:
>>> Sorry Christoph, I'm completely newbie in NVMe and don't know what "Namespace Write Protection Config" means.
>>
>> Take a look at
>> https://nvmexpress.org/wp-content/uploads/NVM-Express-Base-Specification-2.0b-2021.12.18-Ratified.pdf
>> and search for this term.
> 
> Thank you for the specs.
> 
>>> What I mean is that all the NVMe content seen by the user is write protected.
>>
>> And that is what this feature is abut.
>>
>>> Our NVMe manufacturer partner has dedicated a pin of the module for global write protection.
>>
>> There is no concept of a 'module' in NVMe.
> 
> In fact this is a M.2 module : a M.2 PCIe SSD one. A M.2 GND pin has been reused for WP with a pull-up on module, so that if the module is plugged into a standard M.2 socket this pin is connected to GND and the module is not protected. And in a socket providing WP on this pin, the write protection can be enabled by setting the pin high or unconnected.
> 
In other words, your firmware needs to set bit 0 in the ID-NS's NSATTR 
field [1] in the Identify Namespace data structure(s) when WP pin is 
grounded.


>>> But if we enable this protection and attempt a write (we should not), we get a "critical medium error" which seems a bit brutal for a disk that is still valid but just write protected. So I would like to make sure the NVMe manufacturer has used the right method/status to report this write protection, and if possible get a less fatal error feedback.
>>
>> It seems like your manufacturer needs to read the NVMe spec and implement the correct features.
> 
> Yes, that's why I requested some tips from experts like you to be sure.
> And with the features implemented correctly, is a the case of a write to a protected module already handled/expected by the kernel ? and what message the kernel is expected to report in dmesg ?
Search for 'Write Protected'/'Write Protection' in [1] spec.
You will need to support certain command Status Codes in the controller 
to convey state information on commands that may change the namespace.

[1] NVM Express Base Spec 2.0b, Figure 280
https://nvmexpress.org/wp-content/uploads/NVM-Express-Base-Specification-2.0b-2021.12.18-Ratified.pdf

Re: NVMe write protection support

[Jonathan Derrick]

On 8/26/2022 1:39 PM, Jonathan Derrick wrote:
> 
> 
> On 8/25/2022 2:26 AM, Gilles Buloz wrote:
>>> On Sat, Aug 06, 2022 at 10:35:00 AM +0100, Christoph Hellwig wrote:
>>>> On Tue, Aug 02, 2022 at 09:20:02AM +0000, Gilles Buloz wrote:
>>>> Sorry Christoph, I'm completely newbie in NVMe and don't know what 
>>>> "Namespace Write Protection Config" means.
>>>
>>> Take a look at
>>> https://nvmexpress.org/wp-content/uploads/NVM-Express-Base-Specification-2.0b-2021.12.18-Ratified.pdf 
>>>
>>> and search for this term.
>>
>> Thank you for the specs.
>>
>>>> What I mean is that all the NVMe content seen by the user is write 
>>>> protected.
>>>
>>> And that is what this feature is abut.
>>>
>>>> Our NVMe manufacturer partner has dedicated a pin of the module for 
>>>> global write protection.
>>>
>>> There is no concept of a 'module' in NVMe.
>>
>> In fact this is a M.2 module : a M.2 PCIe SSD one. A M.2 GND pin has 
>> been reused for WP with a pull-up on module, so that if the module is 
>> plugged into a standard M.2 socket this pin is connected to GND and 
>> the module is not protected. And in a socket providing WP on this pin, 
>> the write protection can be enabled by setting the pin high or 
>> unconnected.
>>
> In other words, your firmware needs to set bit 0 in the ID-NS's NSATTR 
> field [1] in the Identify Namespace data structure(s) when WP pin is 
> grounded.
s/grounded/set

> 
> 
>>>> But if we enable this protection and attempt a write (we should 
>>>> not), we get a "critical medium error" which seems a bit brutal for 
>>>> a disk that is still valid but just write protected. So I would like 
>>>> to make sure the NVMe manufacturer has used the right method/status 
>>>> to report this write protection, and if possible get a less fatal 
>>>> error feedback.
>>>
>>> It seems like your manufacturer needs to read the NVMe spec and 
>>> implement the correct features.
>>
>> Yes, that's why I requested some tips from experts like you to be sure.
>> And with the features implemented correctly, is a the case of a write 
>> to a protected module already handled/expected by the kernel ? and 
>> what message the kernel is expected to report in dmesg ?
> Search for 'Write Protected'/'Write Protection' in [1] spec.
> You will need to support certain command Status Codes in the controller 
> to convey state information on commands that may change the namespace.
> 
> [1] NVM Express Base Spec 2.0b, Figure 280
> https://nvmexpress.org/wp-content/uploads/NVM-Express-Base-Specification-2.0b-2021.12.18-Ratified.pdf 
> 

Re: NVMe write protection support

[Gilles BULOZ]

Hi Jonathan,

Having a look to the specs at chapter "8.12 Namespace Write Protection", I see
"Figure 430 defines the transition between write protection states. All state transitions are based on Set Features commands unless 
otherwise specified. The initial state of a namespace at the time of its creation is the No Write Protect state."
But in my case the WP pin when enabled would make the initial state of the namespace at the time of its creation be "Write Protect". 
Or I could simulate a transition from "No Write Protect" to "Write Protect" but this would be without "Set Features" command.
In both cases I would be out of specs.

Also if the implementation is correct in the NVMe, and assuming the kernel already supports this case gracefully, what king of 
kernel message would I get (in dmesg) in case of a write to a protected device ?

On 8/26/2022 9:40 PM, Jonathan Derrick wrote:
>
> On 8/26/2022 1:39 PM, Jonathan Derrick wrote:
>>
>>
>> On 8/25/2022 2:26 AM, Gilles Buloz wrote:
>>>> On Sat, Aug 06, 2022 at 10:35:00 AM +0100, Christoph Hellwig wrote:
>>>>> On Tue, Aug 02, 2022 at 09:20:02AM +0000, Gilles Buloz wrote:
>>>>> Sorry Christoph, I'm completely newbie in NVMe and don't know what
>>>>> "Namespace Write Protection Config" means.
>>>>
>>>> Take a look at
>>>> https://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fnvmexpress.org%2Fwp-content%2Fuploads%2FNVM-Express-Base-Specification-2.0b-2021.12.18-Ratified.pdf&data=05%7C01%7CGilles.Buloz%40kontron.com%7C1d97e0a70c1c4da35b4c08da879acb89%7C8c9d3c973fd941c8a2b1646f3942daf1%7C0%7C0%7C637971396556129208%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=CUa2QovHH9%2BWJH001d3vDHrSD%2F3KyKuhigo4EuQ4GbM%3D&reserved=0 
>>>>
>>>>
>>>> and search for this term.
>>>
>>> Thank you for the specs.
>>>
>>>>> What I mean is that all the NVMe content seen by the user is write
>>>>> protected.
>>>>
>>>> And that is what this feature is abut.
>>>>
>>>>> Our NVMe manufacturer partner has dedicated a pin of the module for
>>>>> global write protection.
>>>>
>>>> There is no concept of a 'module' in NVMe.
>>>
>>> In fact this is a M.2 module : a M.2 PCIe SSD one. A M.2 GND pin has
>>> been reused for WP with a pull-up on module, so that if the module is
>>> plugged into a standard M.2 socket this pin is connected to GND and
>>> the module is not protected. And in a socket providing WP on this pin,
>>> the write protection can be enabled by setting the pin high or
>>> unconnected.
>>>
>> In other words, your firmware needs to set bit 0 in the ID-NS's NSATTR
>> field [1] in the Identify Namespace data structure(s) when WP pin is
>> grounded.
> s/grounded/set
>
>>
>>
>>>>> But if we enable this protection and attempt a write (we should
>>>>> not), we get a "critical medium error" which seems a bit brutal for
>>>>> a disk that is still valid but just write protected. So I would like
>>>>> to make sure the NVMe manufacturer has used the right method/status
>>>>> to report this write protection, and if possible get a less fatal
>>>>> error feedback.
>>>>
>>>> It seems like your manufacturer needs to read the NVMe spec and
>>>> implement the correct features.
>>>
>>> Yes, that's why I requested some tips from experts like you to be sure.
>>> And with the features implemented correctly, is a the case of a write
>>> to a protected module already handled/expected by the kernel ? and
>>> what message the kernel is expected to report in dmesg ?
>> Search for 'Write Protected'/'Write Protection' in [1] spec.
>> You will need to support certain command Status Codes in the controller
>> to convey state information on commands that may change the namespace.
>>
>> [1] NVM Express Base Spec 2.0b, Figure 280
>> https://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fnvmexpress.org%2Fwp-content%2Fuploads%2FNVM-Express-Base-Specification-2.0b-2021.12.18-Ratified.pdf&data=05%7C01%7CGilles.Buloz%40kontron.com%7C1d97e0a70c1c4da35b4c08da879acb89%7C8c9d3c973fd941c8a2b1646f3942daf1%7C0%7C0%7C637971396556285269%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=3xwpGWKfZwzL7PAisPNw9zRJTubYQjNxtoK3jCYufYU%3D&reserved=0 
>>
>>
> .

Re: NVMe write protection support

[Christoph Hellwig]

On Tue, Sep 13, 2022 at 07:17:57PM +0200, Gilles BULOZ wrote:
> But in my case the WP pin when enabled would make the initial state of the
> namespace at the time of its creation be "Write Protect". Or I could
> simulate a transition from "No Write Protect" to "Write Protect" but this
> would be without "Set Features" command.
> In both cases I would be out of specs.

I don't think you need that.  Just set bit 0 of the NSATTR field in
the Identify Namespace stucture to 1 and ignore the Set/Get Features
parts.  If your pin can be chaned at runtime, make sure that the bit
is updated based on it and that the Namespace Attribute Changed
AEN is sent when that happens.

> Also if the implementation is correct in the NVMe, and assuming the kernel
> already supports this case gracefully, what king of kernel message would I
> get (in dmesg) in case of a write to a protected device ?

Opening a block devie that was set to read only before will return
-EACCES.  If it is set to read-only after it was opened there is no
special handling and you'll get a good old -EIO.

Re: NVMe write protection support

[Gilles BULOZ]

Hi Christoph,
Our disk manufacturer told me their NVMe does not follow NVMe specification 2.0 but 1.3.
Is there also something in 1.3 to handle the write protection cleanly ?
Currently the only thing I get is a medium error, or an I/O error due to an aborted command leading to problems even when working at 
block device level (using dd) : the device file /dev/nvme0n1 disappears ! So I can't imaging what this would do with a real 
filesystem on top of that.
I'm using kernel 5.18.13 (fedora 36 with updates)
Thanks
Gilles

Le 19/09/2022 à 16:59, Christoph Hellwig a écrit :
> On Tue, Sep 13, 2022 at 07:17:57PM +0200, Gilles BULOZ wrote:
>> But in my case the WP pin when enabled would make the initial state of the
>> namespace at the time of its creation be "Write Protect". Or I could
>> simulate a transition from "No Write Protect" to "Write Protect" but this
>> would be without "Set Features" command.
>> In both cases I would be out of specs.
> I don't think you need that.  Just set bit 0 of the NSATTR field in
> the Identify Namespace stucture to 1 and ignore the Set/Get Features
> parts.  If your pin can be chaned at runtime, make sure that the bit
> is updated based on it and that the Namespace Attribute Changed
> AEN is sent when that happens.
>
>> Also if the implementation is correct in the NVMe, and assuming the kernel
>> already supports this case gracefully, what king of kernel message would I
>> get (in dmesg) in case of a write to a protected device ?
> Opening a block devie that was set to read only before will return
> -EACCES.  If it is set to read-only after it was opened there is no
> special handling and you'll get a good old -EIO.
>
> .

Re: NVMe write protection support

[Christoph Hellwig]

On Fri, Sep 30, 2022 at 07:49:38PM +0200, Gilles BULOZ wrote:
> Hi Christoph,
> Our disk manufacturer told me their NVMe does not follow NVMe specification 2.0 but 1.3.
> Is there also something in 1.3 to handle the write protection cleanly ?

NVMe 1.3 has not write protection feature.  That being NVMe is designed
so that new functionality (new TPs in NVMe terms) can be implemented by
devices that comply to older versions.  So if you just set the bit as
described earlier Linux (and other drivers that know about the feature)
will still do the right thing even if the compliance level is left as
NVM 1.3.

Re: NVMe write protection support

[Gilles BULOZ]

Le 03/10/2022 à 08:24, Christoph Hellwig a écrit :
> On Fri, Sep 30, 2022 at 07:49:38PM +0200, Gilles BULOZ wrote:
>> Hi Christoph,
>> Our disk manufacturer told me their NVMe does not follow NVMe specification 2.0 but 1.3.
>> Is there also something in 1.3 to handle the write protection cleanly ?
> NVMe 1.3 has not write protection feature.  That being NVMe is designed
> so that new functionality (new TPs in NVMe terms) can be implemented by
> devices that comply to older versions.  So if you just set the bit as
> described earlier Linux (and other drivers that know about the feature)
> will still do the right thing even if the compliance level is left as
> NVM 1.3.
> .
Hi Christoph,
I confirm that setting the WP state in the Namespace Attribute (NSATTR) before Linux boot (without changing it later) leads to the 
expected result : writing to the device file when protected returns "Operation not permitted", and booting Linux (Fedora 36) from 
the device leads to filesystems mounted as expected in read-only mode (writing to them returns "Read-only file system") giving a 
functional system.
Thanks very much to you and others for the time spent on it.