libfdt issue - key verification fails with longer key-name

[Heiko Stuebner]

Hi Simon,

Am Dienstag, 28. April 2020, 00:25:06 CEST schrieb Simon Glass:
> 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?

it really seems to be an alignment-bug ... the rsa-mod-exp code
assumes an u64-alignment when that is not guaranteed.

See the patch titled
	"rsa: fix alignment issue when getting public exponent"
I sent just now.

Heiko