From mboxrd@z Thu Jan 1 00:00:00 1970 From: Heiko Stuebner Date: Sun, 03 May 2020 13:28:15 +0200 Subject: libfdt issue - key verification fails with longer key-name In-Reply-To: References: <2679719.CzFn5IKveB@diego> Message-ID: <2139753.xU6ePxLz2D@diego> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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 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