public inbox for linux-nvme@lists.infradead.org
 help / color / mirror / Atom feed
From: Jonathan Derrick <jonathan.derrick@linux.dev>
To: Gilles Buloz <Gilles.Buloz@kontron.com>,
	Christoph Hellwig <hch@infradead.org>
Cc: "linux-nvme@lists.infradead.org" <linux-nvme@lists.infradead.org>
Subject: Re: NVMe write protection support
Date: Fri, 26 Aug 2022 13:39:31 -0600	[thread overview]
Message-ID: <6a50bd55-e8be-283d-1e57-731958bd1820@linux.dev> (raw)
In-Reply-To: <DU0PR10MB6252E237D18FCFB37CB17B8F80729@DU0PR10MB6252.EURPRD10.PROD.OUTLOOK.COM>



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


  reply	other threads:[~2022-08-26 19:46 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-01  8:36 NVMe write protection support Gilles Buloz
2022-08-01 10:01 ` Chao Leng
2022-08-01 12:41   ` Gilles BULOZ
2022-08-01 16:39     ` Keith Busch
2022-08-01 18:34 ` Christoph Hellwig
2022-08-02  9:20   ` Gilles Buloz
2022-08-06  8:35     ` Christoph Hellwig
2022-08-25  8:26       ` Gilles Buloz
2022-08-26 19:39         ` Jonathan Derrick [this message]
2022-08-26 19:40           ` Jonathan Derrick
2022-09-13 17:17             ` Gilles BULOZ
2022-09-19 14:59               ` Christoph Hellwig
2022-09-30 17:49                 ` Gilles BULOZ
2022-10-03  6:24                   ` Christoph Hellwig
2022-10-20 17:31                     ` Gilles BULOZ

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=6a50bd55-e8be-283d-1e57-731958bd1820@linux.dev \
    --to=jonathan.derrick@linux.dev \
    --cc=Gilles.Buloz@kontron.com \
    --cc=hch@infradead.org \
    --cc=linux-nvme@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox