libfdt issue - key verification fails with longer key-name
sjg at chromium.org
Tue Apr 28 00:25:06 CEST 2020
On Sun, 26 Apr 2020 at 17:55, Heiko Stuebner
<heiko.stuebner at theobroma-systems.com> wrote:
> I've encountered a strange issue that happens depending on the
> length of the used key-name. Naming it "integrity" works,
> "integrity-uboot" or even "integrity-ub" does not.
> With the resulting key-node of course then being "key-integrity-uboot".
> On the upper levels everything looks great, it finds the signatures and
> correct key-node, but when the spl reaches the
> rsa_verify_with_keynode() function it falls apart and libfdt seems to read
> strange values from the fdt.
> Single values seem to be read back correctly, as can be seen with
> rsa,n0-inverse and rsa,num-bits values that are correct with both
> key-names (for the same base key).
> But it's different with the public exponent rsa,exponent:
> Where it reads back in the correct case as 0x0000 0000 0001 0001
> with the longer keyname the result is i.e. 0x44b2 0100 0000 0000
> (or similar, depending on the length of the keyname it seems).
> The 0x0100 part stays the same always, but the 0x44b2 can also be
> a 0xecb1
> Is this some alignment issue somewhere, or do you have a hint
> what I should poke?
Not really, but can you repeat it with sandbox? It sounds like it
could be a bug?
More information about the U-Boot