Re: [PATCH 0/6] k3-binman ergonomics

[Anshul Dalal <anshuld@ti.com>]

On Mon Jul 13, 2026 at 6:24 PM IST, Rasmus Villemoes wrote:
> On Mon, Jul 13 2026, "Anshul Dalal" <anshuld@ti.com> wrote:
>
>> On Fri Jul 10, 2026 at 6:06 PM IST, Rasmus Villemoes wrote:
>>> When trying to hook up use of a customer's own signing infrastructure
>>> for some am62x devices, I found it was more difficult than it should
>>> be to point at the right key(s). One has to patch in the keyfile=
>>> property in way too many places, and if you miss just one, the build
>>> succeeds using the generic custMpk.pem for the one you missed, but of
>>> course the resulting artifacts are unbootable.
>>>
>>
>> The default value for keyfile i.e custMpk.pem is generated via binman
>> from the custMpk node in binman (defined in k3-binman.dtsi), modifying
>> the filepath to your custom key should work as a single line change as
>> is.
>>
>
> No, because I don't have and will not have the "key" as an actual
> file. And nobody who really cares about security should expose their
> signing keys to the build environment. So I cannot simply change how the
> custMpk.pem key in the (top-level) build-directory gets generated from
> the one in the source tree.
>
> I'm using a pkcs11:object=... uri as the keyfile property - that
> works just fine out-of-the-box with a suitable OPENSSL_CONF in the
> environment, so that openssl picks up the right pkcs11 provider module
> and gets a signature that way.
>
> So I really need a way for having a single place to set keyfile =
> "pkcs11:object=..." and have that be used in all relevant nodes. Yes, I
> see that I should have emphasized that use case more in the commit log
> for patch 4, using that as example instead of "/path/to/own/key.pem".
>
> [In my concrete case, the signing is done by a remote service, but it
> would really be the same issue if one were using a yubikey or some other
> local HSM].
>

I see the use case now, what we have here makes sense. To add to what
Simon said[1] a small section documenting the use of pkcss11:object
inside the node in the k3.rst doc would be good to see.

[1]: https://lore.kernel.org/u-boot/CAFLszTh=4fWg6L74vnaJz7O9kOxE68XP3BCJEWVnBvc1aopHJg@mail.gmail.com/

>> Perhaps this could be made more clear by the use of a macro instead of
>> hardcoding the string "custMpk.pem" in all the places to make it more
>> obvious.
>
> Sure, we could introduce a macro and do
>
> #ifndef K3_KEYFILE
> #define K3_KEYFILE "custMpk.pem"
> #endif
>
> at the top of k3-binman.dtsi, but since binman already has the template
> mechanism, that seemed a lot more appropriate to use.

That's fair, we wouldn't need a macro if we replace all instances of
custMpk with the template. I can take that up once this is merged.

Thanks for the patch,
Anshul