Sending vendor specific commands to spi-nor flash

[Paul Barker]

On 23/05/2022 09:31, Michael Walle wrote:
> Hi,
> 
> Am 2022-05-18 14:32, schrieb Paul Barker:
>> We're looking to add support for sending vendor specific commands to
>> Micron Authenta flash devices over the SPI bus.
> 
> Please elaborate a bit more on the use case. Is this something specific
> to the flash or is it more of a general feature?

The Authenta flash devices support two groups of vendor-specific commands:

1) "Advanced Sector Protection" commands, common to several Micron 
parts. These include volatile & non-volatile lock bits, password 
protection and a global freeze bit.

2) "Authenticated Core Root of Trust for Measurement (A-CRTM)" commands, 
specific to Authenta flash devices. These include authenticated write 
operations where the data to be written must be signed with a 
cryptographic key and measurement operations which allow remote 
attestation of the contents of the flash. These features interact with 
the cloud-based Authenta Key Management Service (KMS) provided by Micron 
and user-controlled cryptographic keys can also be supported for these 
devices.

To make use of these features vendor-specific commands are sent to the 
flash device. We expect to send these commands during the boot process 
and during the process of securely deploying a new software image to the 
flash device.

Brief information on the Authenta features is available as a PDF [1].

[1]: 
https://media-www.micron.com/-/media/client/global/documents/products/data-sheet/nor-flash/serial-nor/mt25q/mt25q_a_crtm_rpmc_addendum_rev_1_6_brief.pdf 


> 
>> Since we're using the
>> MTD block interface to support a filesystem on the SPI flash we need
>> to send these vendor specific commands via some sort of IOCTL.
>>
>> I can see a couple of ways to achieve this (as follows) and would like
>> to get some feedback from the MTD & spi-nor maintainers on which
>> approach is preferred:
>>
>> 1) Add new IOCTLs to the mtdchar device to support these vendor
>> specific operations. An initial set of patches was sent back in
>> October 2021 which took this route [1], but no further progress was
>> made. The new IOCTLs would exist for all mtdchar devices (regardless
>> of vendor) if we go this route and we'd need to ensure -EINVAL or
>> -ENOTSUPP is returned as appropriate if these IOCTLs are called on a
>> device which does not implement them.
>>
>> 2) Add a vendor-specific IOCTL layer to the mtdchar device interface.
>> When the mtdchar IOCTL handler is called with a command not defined in
>> mtdchar.c, pass the call on to a device-specific IOCTL handler which
>> can potentially handle vendor specific commands.
>>
>> 3) Add a generic SPI transfer IOCTL for spi-nor MTD devices. This
>> would avoid the need to define IOCTLs for every vendor specific
>> command supported by SPI flash devices. Instead, knowledge of the
>> vendor specific commands would be kept in userspace and the kernel
>> would simply provide an API for sending & receiving arbitrary bytes
>> over the SPI bus. This is similar to the MMC_IOC_CMD IOCTL supported
>> by the MMC driver.
>>
>> My preference would be for option (3) since it minimizes the scope of
>> the changes we need to make in the kernel. We're not tied to this
>> though, so let us know if a different option is preferred.
> 
> I'm not sure we should allow a generic "issue anything to the spi
> flash". It it is just a one time thing, like for example, program
> a password during production, or program non-volatile memory during
> production of the board, I'm fine with it. Most probably, calling
> that ioctl will also call add_taint(). This will also need to go
> with proper userspace util support.
> 
> But if it is something for general use, please provide a proper API
> and don't write userspace drivers.

I've been looking at how the eMMC/SD and NVMe drivers support passing 
through vendor specific commands using MMC_IOC_CMD for eMMC/SD and 
NVME_IOCTL_ADMIN_CMD/NVME_IOCTL_IO_CMD for NVMe. Neither of these ioctl 
handlers appear to call add_taint().

For A-CRTM operations, in our current use case the command bytes to be 
sent over the SPI bus to the flash device are sent from a cloud-based 
service to a userspace agent on the device. The agent simply needs a way 
to pass these command bytes over the SPI bus to the device and retrieve 
the sequence of response bytes to send back to the cloud-based service. 
For this we could use either a generic SPI transfer IOCTL or a Micron 
specific A-CRTM command IOCTL.

For the Advanced Sector Protection commands we can add IOCTLs for each 
command if that's the preferred approach. The command list can be seen 
on page 35 of the datasheet for the MT25QL02GCBB spi-nor flash device 
[2] and on other Micron flash device datasheets.

[2]: 
https://media-www.micron.com/-/media/client/global/documents/products/data-sheet/nor-flash/serial-nor/mt25q/die-rev-b/mt25q_qlkt_l_02g_cbb_0.pdf

We're happy to look at extending libmtd and/or mtd-utils to wrap any 
IOCTLs added to the drivers. Would that provide the proper API you're 
looking for?

Thanks,

-- 
Paul Barker
Principal Software Engineer
SanCloud Ltd

e: paul.barker at sancloud.com
w: https://sancloud.com/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_0xA67255DFCCE62ECD.asc
Type: application/pgp-keys
Size: 7526 bytes
Desc: OpenPGP public key
URL: <http://lists.infradead.org/pipermail/linux-mtd/attachments/20220523/9abd30ae/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 236 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-mtd/attachments/20220523/9abd30ae/attachment.sig>