[PATCH v2 3/4] tools: binman: fit: add support for OpenSSL engines

[Quentin Schulz]

On 11/19/25 4:06 PM, Wolfgang Wallner wrote:
> Hi Quentin,
> 
> From: Quentin Schulz <quentin.schulz at cherry.de>
>> Hi Wolfgang,
>>
>> [...]
>>
>>>
>>> This description is quite convoluted. I would propose to describe it as a list,
>>
>> I'm very good at writing convoluted paragraphs, so thanks for suggesting
>> something more readable :)
>>
>>> something like the following:
>>>
>>> When `fit,engine` is set to `pkcs11`, the following cases are distinguished
>>> regarding the value of `fit,engine-keydir`:
>>>
>>>     - If `fit,engine-keydir` is not present, value of `key-name-hint` is prefixed
>>>       with `pkcs11:object=`, and then passed as-is to the OpenSSL engine API.
>>>
>>>       PKCS#11 id: `pkcs11:object=<key-name-hint>`
>>
>> I have no experience with PKCS#11, but shouldn't that rather be a
>> "PKCS#11 URI" instead if " PKCS#11 id"?
> 
> Yes, of course, my formulation was sloppy here. Please use the term URI.
> 

I'm now wondering if I'm not just going too far into explaining what 
happens to fit,engine-keydir. It is after all passed verbatim as -k 
argument to mkimage. The special cases for pkcs11 are all internal to 
mkimage so I'm not sure if fit,engine-keydir is the best place to 
document that? That could drastically simplify the documentation for the 
fit entry in binman.

[...]

>> I was wondering if you had experience with using id= in the pkcs11 URI?
> 
> Thanks for pointing that out, I have now additionally tested with 'id=%01%02%03':
>      fit,sign;
>      fit,engine = "pkcs11";
>      fit,engine-keydir = "pkcs11:id=<id-of-my-key>";
>      key-name-hint = "MyTestKey";
>      

Any chance I can get some softhsm2-util command to generate that object 
with that id :) I wasn't able to last time I tried with id=999999 or 
id=%999999 (since that's what I set the id of the key when importing) in 
the test :/ Possibly PEBKAC though :)

> There is one other aspect of the current solution that I'm not sure about:
>   * key-name-hint is an attribute per signature
>   * fit,engine-keydir is an attribute once per FIT description
>   
> I don't know wheter this is a use case for anyone, but I think if one would
> like to have multiple signature nodes in a FIT description (e.g. multiple
> configurations) and would like to have them signed with different keys, then
> it would only be possible to do that via the key-name-hint, and thus only
> via "object=xxx", but not via "id=xxx".
> 
As far as I know (but happy to be proven otherwise), this is not 
possible with mkimage right now. But note that I too was bothered while 
looking at what was possible with mkimage. In the end, I don't need it 
but I could see it being useful. On Rockchip, we typically only need to 
sign one FIT: U-Boot proper, and everything is validated by SPL before 
loading TF-A (bl31), TEE (bl32) and U-Boot proper before jumping into 
BL31 so there really isn't a use case here. The kernel FIT which could 
be verified by U-Boot proper before booting is anyway a different FIT so 
can have a different engine or engine-keydir.

I think we would need to use a per-signature-node Device Tree property 
to specify which engine (if any) to use and which arguments to pass with 
the engine as well (still per-signature-node; not using the -k argument 
anymore for that). This is something that needs to be supported in 
mkimage though, with possible additions to the FIT spec (though it is 
arguable). This would allow to use a different engine (or not even using 
an engine) for encryption vs signing, which we currently cannot do.

Cheers,
Quentin