On Sat, 17 Oct 2026, Simon Glass wrote:
Hi Yan,
On 2026-10-12T10:47:59, Yan WANG <[email protected]> wrote:
The implementation builds on the existing pkcs11_tool btool: a sign()
method is added that drives pkcs11-tool to perform the actual
cryptographic operation.
Binman can already describe a PKCS#11 key for FIT signing: fit,engine
set to pkcs11, with fit,engine-keydir and key-name-hint, which become
a pkcs11: URI. This series adds a second scheme of eight properties
that works quite differently. It would be better for users if pre-load
followed the FIT conventions, e.g. a single PKCS#11 URI property for
the token and key plus the module path. Then both entry types would be
configured the same way. What do you think?
I have another idea, not directly related to this patch (this could also
be used in mkimage) - would a two-step asynchronous process be acceptable?
First step, binman calculates byte ranges to be signed and provides
a value (possibly a hash) that can be fed to a signing process.
External process talks to the HSM via the interface of choice
and provides a ready-to-embed signature for the actual binman run.
Yes, this breaks the notion "only run binman once", unfortunately.
That would decouple us from the openssl engine/pkcs11/whatever interfaces
and also could enable enterprise-grade workflows where signing
a production image involves approvals, n-of-m or whatever additional
protections might be needed.
Marcin
