[PATCH v3 2/2] binman: x509_cert: add PKCS#11/HSM signing support

[Quentin Schulz]

Hi Sergio,

On 4/30/26 8:23 PM, Sergio Prado wrote:
> Hi Quentin,
> 
> On 4/28/26 X:XX PM, Quentin Schulz wrote:
> 
>> +BINMAN_PKCS11_MODULE
>> +    Path to the PKCS#11 shared library (.so) for HSM signing. When set,
> it is
>> +    passed as ``-a pkcs11-module=<path>`` to binman. Only needed when the
>> +    module is not already configured via ``openssl.cnf`` or the
>> +    ``PKCS11_MODULE_PATH`` environment variable. Typically used together
> with
>> +    ``BINMAN_PKCS11_URI``::
>>
>> OK, but why do we want to have this variable for storing the path to the
>> module lib instead of using an openssl.cnf?
> 
> Agreed. I’ll drop BINMAN_PKCS11_MODULE and rely on external OpenSSL
> configuration (openssl.cnf) instead.
> 
>> Also, this is stating it's for signing boot artifacts with an HSM, but
>> that isn't true. It won't work with FIT images, which use DT properties
>> instead (see fit,engine, fit,engine-keydir/key-name-hint.).
>>
>> I'm assuming it's possible we want different keys for different boot
>> artifacts, so this is also a bit too generic of a name?
> 
> Good point. I’ll scope this more precisely to X.509 usage. Would
> BINMAN_X509_PKCS11_URI be appropriate, or do you have a preferred naming
> convention here?
> 

Is this really PKCS11-specific? Is there no other way to get an x509 
than by PKCS11 or plaintext file? Trying to think about potentially 
having other providers needing something similar and then setting 
BINMAN_X509_PKCS11_URI for that would be confusing.

>> +# Serializes concurrent PKCS#11 signing operations. SoftHSM2 and many
> real
>> +# HSMs do not support simultaneous logins from multiple threads, so
> binman's
>> +# ThreadPoolExecutor would otherwise cause intermittent login failures.
>> +_pkcs11_lock = threading.Lock()
>>
>> Is there really no external mechanism to make sure this cannot happen?
>> or maybe some sort of session concept?
>>
>> binman tests will run on multiple processes (see ConcurrentTestSuite)
>> when not instructed to run on one thread (via -T 0, used for test
>> coverage). My worry is whether this is multiprocess safe (hunch is no).
> 
> OK. I’ll investigate whether this can be handled externally (e.g. via
> token/session configuration) or if a more robust approach is needed.
> 
>> +    def _pkcs11_use_provider(self):
>> +        """Return True if the provider API should be used for PKCS#11
> signing.
>> +        ...
>> +        """
>> +        if self._use_provider is None:
>> +            out = self.run_cmd('list', '-providers') or ''
>> +            self._use_provider = 'pkcs11' in out
>> +        return self._use_provider
>>
>> Why force the user to use providers if one is available? Can't they use
>> an engine even if a pkcs11 provider is available (e.g. you have both
>> pkcs11 provider support via softhsm2, but only engine support for your
>> HSM). Isn't this something the user can specify via openssl.cnf?
> 
>  From my testing with SoftHSM2:
> 
> - Provider-based flow: configuring openssl.cnf is sufficient. OpenSSL
> dispatches "pkcs11:" URIs via the STORE API without additional CLI
> arguments.
> - Engine-based flow: configuring the engine in openssl.cnf alone is not
> sufficient; "-engine pkcs11 -keyform engine" must still be passed
> explicitly.
> 

Being curious now, I'm wondering if setting the -key to 
org.openssl.engine:pkcs11:<key> would be enough on OpenSSL 3.x? C.f. 
https://docs.openssl.org/3.0/man1/openssl/#engine-options

We of course cannot use this when we still support OpenSSL 1.x though.

> I would be fine with supporting provider-based flows only, as it simplifies
> the implementation and covers my use case (OpenEmbedded integration).
> However, I’m concerned about compatibility with older distributions where
> PKCS#11 provider support may not be available by default. What would you
> recommend in this case?
> 

I'm tempted to say "another person's problem". I was already not happy 
to contribute support for OpenSSL engines in FIT signing because it's 
been deprecated for years at that point but I needed it (could have kept 
it downstream though). We just need to make sure it's not impossible to 
support if someone really wants it (and it needs to work with OpenSSL 
1.x I believe, even though it's official EoL you can still buy 
commercial support for it).

Cheers,
Quentin