Re: libfdt issue - key verification fails with longer key-name

2020-05-03 Thread 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
>  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 0x  0001 0001
> > with the longer keyname the result is i.e. 0x44b2 0100  
> > (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




Re: libfdt issue - key verification fails with longer key-name

2020-04-27 Thread Simon Glass
Hi Heiko,

On Sun, 26 Apr 2020 at 17:55, Heiko Stuebner
 wrote:
>
> Hi,
>
> 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 0x  0001 0001
> with the longer keyname the result is i.e. 0x44b2 0100  
> (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?

Regards,
Simon