libfdt issue - key verification fails with longer key-name

libfdt issue - key verification fails with longer key-name

[Heiko Stuebner]

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 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?


Thanks
Heiko

libfdt issue - key verification fails with longer key-name

[Simon Glass]

Hi Heiko,

On Sun, 26 Apr 2020 at 17:55, Heiko Stuebner
<heiko.stuebner@theobroma-systems.com> 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 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?

Regards,
Simon

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@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