libfdt issue - key verification fails with longer key-name
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
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
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
participants (2)
-
Heiko Stuebner -
Simon Glass