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]. > 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. Rasmus
