On Mon Jul 13, 2026 at 6:24 PM IST, Rasmus Villemoes wrote: > On Mon, Jul 13 2026, "Anshul Dalal" <[email protected]> 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=4fwg6l74vnajz7o9koxe68xp3bcjewvnbvc1aop...@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
