[U-Boot] Hi Simon, Problems about RSA public exponents for verified boot

[Simon Glass]

Hi,

On 4 December 2014 at 01:38, Michael van der Westhuizen
<michael at smart-africa.com> wrote:
> Hi All,
>
> Apologies for the delayed response, I’ve been on vacation.
>
> Since this was working for you (Duxiaoqiang) previously it suggests that you are using the default public exponent.  If this is still the case you could, as a temporary workaround, remove the public exponent from your public key data to avoid executing the code causing the abort.
>
> Simon: Yes, we’ll need an alignment-safe version of fdt64_to_cpu.

OK, if someone can test and send a patch I can apply it.

Regards,
Simon

>
> Michael
>
>> On 02 Dec 2014, at 12:31 AM, Simon Glass <sjg at chromium.org> wrote:
>>
>> +Michael, U-Boot mailing list
>>
>> Hi,
>>
>> On 30 November 2014 at 19:26, Duxiaoqiang <duxiaoqiang at huawei.com> wrote:
>>>
>>> Hi Simon
>>>
>>>
>>>
>>> When I test verified boot with new version of U-boot and new version of mkimage, I encountered a alignment problem about RSA public key exponents.
>>>
>>>
>>>
>>> I tested verified boot successful few months ago with version of 2014.07-rc4, but failed with the same configuration and operations this time.
>>>
>>>
>>>
>>> Problem logs as below:
>>>
>>>
>>>
>>>
>>>
>>> I debug this problem and noticed that the problem was caused by pulic_exponent’s address: 0xff78a04c, this address was not aligned to 8 byte, but this address was pointed by a uint64 * type of pointer.
>>>
>>> Panic happened in function rsa_verify_with_keynode, just as below:
>>>
>>>
>>>
>>> By compared the u-boot.dtb file that signed with RSA public key, I noticed that there are differences about PUBLIC_EXPONENT.
>>>
>>> With the older version of mkimage, there’s no public exponent section. And this problem only happens when I use the new version of mkimage tool.
>>>
>>>
>>>
>>> I also checked uboot’s code, it seems that there’s lack of mechanism to guarantee the alignment about public exponent section.
>>>
>>>
>>>
>>> Can you give some suggestions about this problem. Appreciate your time.
>>
>> Copying Michael. Perhaps we need a safer version of fdt64_to_cpu()?
>>
>> But you might be the first to run this on aarch64. I have not tried it
>> yet, but I do now have a platform.
>>
>> Regards,
>> Simon
>