* Sending vendor specific commands to spi-nor flash
@ 2022-05-18 12:32 Paul Barker
2022-05-23 8:31 ` Michael Walle
0 siblings, 1 reply; 6+ messages in thread
From: Paul Barker @ 2022-05-18 12:32 UTC (permalink / raw)
To: Tudor Ambarus, Pratyush Yadav, Michael Walle, Miquel Raynal,
Richard Weinberger, Vignesh Raghavendra, linux-mtd
Cc: Stuart Rubin
[-- Attachment #1.1.1.1: Type: text/plain, Size: 2031 bytes --]
Hi,
We're looking to add support for sending vendor specific commands to
Micron Authenta flash devices over the SPI bus. 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.
[1]:
https://lore.kernel.org/linux-mtd/20211027103352.8879-1-sshivamurthy@micron.com/T/
Regards,
--
Paul Barker
Principal Software Engineer
SanCloud Ltd
e: paul.barker@sancloud.com
w: https://sancloud.com/
[-- Attachment #1.1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 7645 bytes --]
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]
[-- Attachment #2: Type: text/plain, Size: 144 bytes --]
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Sending vendor specific commands to spi-nor flash
2022-05-18 12:32 Sending vendor specific commands to spi-nor flash Paul Barker
@ 2022-05-23 8:31 ` Michael Walle
2022-05-23 10:02 ` Paul Barker
0 siblings, 1 reply; 6+ messages in thread
From: Michael Walle @ 2022-05-23 8:31 UTC (permalink / raw)
To: Paul Barker
Cc: Tudor Ambarus, Pratyush Yadav, Miquel Raynal, Richard Weinberger,
Vignesh Raghavendra, linux-mtd, Stuart Rubin
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?
> 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.
-michael
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Sending vendor specific commands to spi-nor flash
2022-05-23 8:31 ` Michael Walle
@ 2022-05-23 10:02 ` Paul Barker
2022-05-23 11:25 ` Michael Walle
0 siblings, 1 reply; 6+ messages in thread
From: Paul Barker @ 2022-05-23 10:02 UTC (permalink / raw)
To: Michael Walle
Cc: Tudor Ambarus, Pratyush Yadav, Miquel Raynal, Richard Weinberger,
Vignesh Raghavendra, linux-mtd, Stuart Rubin
[-- Attachment #1.1.1.1: Type: text/plain, Size: 5299 bytes --]
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@sancloud.com
w: https://sancloud.com/
[-- Attachment #1.1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 7645 bytes --]
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]
[-- Attachment #2: Type: text/plain, Size: 144 bytes --]
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Sending vendor specific commands to spi-nor flash
2022-05-23 10:02 ` Paul Barker
@ 2022-05-23 11:25 ` Michael Walle
2022-06-07 13:50 ` Paul Barker
0 siblings, 1 reply; 6+ messages in thread
From: Michael Walle @ 2022-05-23 11:25 UTC (permalink / raw)
To: Paul Barker, linux-integrity, linux-security-module
Cc: Tudor Ambarus, Pratyush Yadav, Miquel Raynal, Richard Weinberger,
Vignesh Raghavendra, linux-mtd, Stuart Rubin
[+ linux-security-module, linux-integrity, sorry if these are the
wrong MLs, but I don't have any experiences with crypto]
Am 2022-05-23 12:02, schrieb Paul Barker:
> On 23/05/2022 09:31, Michael Walle wrote:
>> 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.
Parts of that isn't really specific to Micron, is it? Sounds like
a per sector locking. AFAIR Tudor was working on advanced sector
protection.
> 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().
I don't know the use case for MMC/NVMe, but until you convince me
otherwise, I see "sending raw commands to the SPI flash" as something
exceptional, and thus you'd taint the kernel.
> 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.
This doesn't sound like a proper abstraction to me. Again, the per
sector lock protection should be integrated into the current locking
ioctls. Regarding the security commands, I'm afraid I can't help
you on that point, but it sounds like bypassing the kernel is the
wrong thing to do.
-michael
>
> [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,
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Sending vendor specific commands to spi-nor flash
2022-05-23 11:25 ` Michael Walle
@ 2022-06-07 13:50 ` Paul Barker
2022-06-20 9:12 ` Paul Barker
0 siblings, 1 reply; 6+ messages in thread
From: Paul Barker @ 2022-06-07 13:50 UTC (permalink / raw)
To: Michael Walle, linux-integrity, linux-security-module
Cc: Tudor Ambarus, Pratyush Yadav, Miquel Raynal, Richard Weinberger,
Vignesh Raghavendra, linux-mtd, Stuart Rubin
Hi Michael, folks,
Apologies for the slow follow-up, I was ill over the last week of May &
start of June.
On 23/05/2022 12:25, Michael Walle wrote:
> [+ linux-security-module, linux-integrity, sorry if these are the
> wrong MLs, but I don't have any experiences with crypto]
>
> Am 2022-05-23 12:02, schrieb Paul Barker:
>> On 23/05/2022 09:31, Michael Walle wrote:
>>> 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.
>
> Parts of that isn't really specific to Micron, is it? Sounds like
> a per sector locking. AFAIR Tudor was working on advanced sector
> protection.
I see your point here. The implementation may be Micron specific but
there are probably ways to improve the generic locking APIs to cover
these features.
I'm happy to look at what Tudor was working on, have any patches been
posted for this? I've searched the mailing list history for the past few
months but can't find any.
>
>> 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().
>
> I don't know the use case for MMC/NVMe, but until you convince me
> otherwise, I see "sending raw commands to the SPI flash" as something
> exceptional, and thus you'd taint the kernel.
Looking at https://docs.kernel.org/admin-guide/tainted-kernels.html, I
can't see any taint flag (tainted state bit) that would apply for the
case when raw commands are sent to a hardware device. I may be
misunderstanding something though - which tainted state bit would be set
by this operation?
>
>> 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.
>
> This doesn't sound like a proper abstraction to me. Again, the per
> sector lock protection should be integrated into the current locking
> ioctls. Regarding the security commands, I'm afraid I can't help
> you on that point, but it sounds like bypassing the kernel is the
> wrong thing to do.
For the Advanced Sector Protection commands I can look into extending
the existing IOCTLs if that's the preferred approach.
For the A-CRTM operations, these don't fit well into the existing APIs.
Furthermore, for several of these operations the bytes sent over the SPI
bus consist of a message block (including an opcode/sub-opcode and any
arguments) followed by a HMAC signature of the message block. The
signing key for this HMAC is typically kept off the device itself (e.g.
in an on-site server or a cloud-based Key Management System). This means
that the sequence of bytes to be sent over the SPI bus is typically
produced by a system which has access to the signing key and is then
sent to the target device to be relayed over the SPI bus to the Authenta
flash device. The kernel running on a system with an Authenta flash
device is typically not in a position to construct and sign the sequence
of bytes to be sent over the SPI bus for A-CRTM commands.
So, I think the best API for A-CRTM operations would be a pair of
vendor-specific IOCTLs, WR_CRTM_CMD and RD_CRTM_CMD, which each take an
array of bytes, including any HMAC signature, to be sent over the SPI
bus to the Authenta flash device. These would check the
opcode/sub-opcode to ensure that they represent a valid A-CRTM command
and for RD_CRTM_CMD to also check that this is an A-CRTM command that
does not modify the device state or flash contents. Thus WR_CRTM_CMD
requires the device to be opened for writing, RD_CRTM_CMD only requires
the device to be opened for reading. Once the opcode/sub-opcode has been
checked the command would be sent to the Authenta flash device and the
response sent back to userspace.
Thanks,
--
Paul Barker
Principal Software Engineer
SanCloud Ltd
e: paul.barker@sancloud.com
w: https://sancloud.com/
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Sending vendor specific commands to spi-nor flash
2022-06-07 13:50 ` Paul Barker
@ 2022-06-20 9:12 ` Paul Barker
0 siblings, 0 replies; 6+ messages in thread
From: Paul Barker @ 2022-06-20 9:12 UTC (permalink / raw)
To: Michael Walle, Tudor Ambarus, Pratyush Yadav, Miquel Raynal,
Richard Weinberger, Vignesh Raghavendra, linux-mtd
Cc: Stuart Rubin, linux-integrity, linux-security-module
[-- Attachment #1.1.1.1: Type: text/plain, Size: 9554 bytes --]
On 07/06/2022 14:50, Paul Barker wrote:
> Hi Michael, folks,
>
> Apologies for the slow follow-up, I was ill over the last week of May &
> start of June.
>
> On 23/05/2022 12:25, Michael Walle wrote:
>> [+ linux-security-module, linux-integrity, sorry if these are the
>> wrong MLs, but I don't have any experiences with crypto]
>>
>> Am 2022-05-23 12:02, schrieb Paul Barker:
>>> On 23/05/2022 09:31, Michael Walle wrote:
>>>> 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.
>>
>> Parts of that isn't really specific to Micron, is it? Sounds like
>> a per sector locking. AFAIR Tudor was working on advanced sector
>> protection.
>
> I see your point here. The implementation may be Micron specific but
> there are probably ways to improve the generic locking APIs to cover
> these features.
>
> I'm happy to look at what Tudor was working on, have any patches been
> posted for this? I've searched the mailing list history for the past few
> months but can't find any.
>
>>
>>> 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().
>>
>> I don't know the use case for MMC/NVMe, but until you convince me
>> otherwise, I see "sending raw commands to the SPI flash" as something
>> exceptional, and thus you'd taint the kernel.
>
> Looking at https://docs.kernel.org/admin-guide/tainted-kernels.html, I
> can't see any taint flag (tainted state bit) that would apply for the
> case when raw commands are sent to a hardware device. I may be
> misunderstanding something though - which tainted state bit would be set
> by this operation?
>
>>
>>> 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.
>>
>> This doesn't sound like a proper abstraction to me. Again, the per
>> sector lock protection should be integrated into the current locking
>> ioctls. Regarding the security commands, I'm afraid I can't help
>> you on that point, but it sounds like bypassing the kernel is the
>> wrong thing to do.
>
> For the Advanced Sector Protection commands I can look into extending
> the existing IOCTLs if that's the preferred approach.
>
> For the A-CRTM operations, these don't fit well into the existing APIs.
> Furthermore, for several of these operations the bytes sent over the SPI
> bus consist of a message block (including an opcode/sub-opcode and any
> arguments) followed by a HMAC signature of the message block. The
> signing key for this HMAC is typically kept off the device itself (e.g.
> in an on-site server or a cloud-based Key Management System). This means
> that the sequence of bytes to be sent over the SPI bus is typically
> produced by a system which has access to the signing key and is then
> sent to the target device to be relayed over the SPI bus to the Authenta
> flash device. The kernel running on a system with an Authenta flash
> device is typically not in a position to construct and sign the sequence
> of bytes to be sent over the SPI bus for A-CRTM commands.
>
> So, I think the best API for A-CRTM operations would be a pair of
> vendor-specific IOCTLs, WR_CRTM_CMD and RD_CRTM_CMD, which each take an
> array of bytes, including any HMAC signature, to be sent over the SPI
> bus to the Authenta flash device. These would check the
> opcode/sub-opcode to ensure that they represent a valid A-CRTM command
> and for RD_CRTM_CMD to also check that this is an A-CRTM command that
> does not modify the device state or flash contents. Thus WR_CRTM_CMD
> requires the device to be opened for writing, RD_CRTM_CMD only requires
> the device to be opened for reading. Once the opcode/sub-opcode has been
> checked the command would be sent to the Authenta flash device and the
> response sent back to userspace.
I'd like to start moving things forward here. I think the best place to
start is going to be to send an initial RFC patch series for the changes
to drivers/mtd/spi-nor/micron-st.c to add wrapper functions for the
Advanced Sector Protection & A-CRTM commands, and add appropriate
entries to micron_nor_parts. That will hopefully improve the context and
we can continue to discuss what is an appropriate API for exposing these
commands to the user space service which needs to invoke them (to
perform actions such as initiating a cryptographic measurement, deriving
a secret key based on a measurement or securely updating a bootloader
image in the flash).
If anyone has any further thoughts at this stage please let us know.
Regards,
--
Paul Barker
Principal Software Engineer
SanCloud Ltd
e: paul.barker@sancloud.com
w: https://sancloud.com/
[-- Attachment #1.1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 7645 bytes --]
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]
[-- Attachment #2: Type: text/plain, Size: 144 bytes --]
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2022-06-20 9:12 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-05-18 12:32 Sending vendor specific commands to spi-nor flash Paul Barker
2022-05-23 8:31 ` Michael Walle
2022-05-23 10:02 ` Paul Barker
2022-05-23 11:25 ` Michael Walle
2022-06-07 13:50 ` Paul Barker
2022-06-20 9:12 ` Paul Barker
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).