Re: [U-Boot] Hi Simon, Problems about RSA public exponents for verified boot
(sorry, forgot to cc list)
On 9 December 2014 at 07:17, Simon Glass sjg@chromium.org wrote:
Hi,
On 8 December 2014 at 01:54, Duxiaoqiang duxiaoqiang@huawei.com wrote:
Hi Michael,
Thanks for your information.
My working result show that public exponent is not the only problem caused by 64bit alignment, there are also some other problems caused by it, for example: load image after verify step.
If you post your console output then perhaps we might be able to suggest a fix.
May be we should add a patch to cover all 64 bit platform's alignment.
For we need verified boot feature to solve some problems, I also spent some time trying to solve the problem.
But I am not very familiar with uboot FDT'S design, it may spend me long time so not very convenient for me to solve this problem.
So I want to know do you have time to fix this problem recently, and what's your plan.
I haven't tried this on 64-bit ARM. I may be able to do so later in the month.
Thanks very much.
Sincerely Jason
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.
Michael
On 02 Dec 2014, at 12:31 AM, Simon Glass sjg@chromium.org wrote:
+Michael, U-Boot mailing list
Hi,
On 30 November 2014 at 19:26, Duxiaoqiang duxiaoqiang@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
Resurrecting this old thread…
Jason,
We’re presently getting CONFIG_OF_EMBED up on a 32 bit PPC target and hit a problem that made me think of this thread.
What we’re seeing (in v2014.07) is that the FDT pointer is not necessarily aligned in the wrapper assembly file. We’ve worked around this with the following patch. You may want to try a similar patch to see if it resolves your problem.
Michael
diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib index 072abaa..987298f 100644 --- a/scripts/Makefile.lib +++ b/scripts/Makefile.lib @@ -251,6 +251,7 @@ quiet_cmd_dt_S_dtb= DTB $@ cmd_dt_S_dtb= \ ( \ echo '.section .dtb.init.rodata,"a"'; \ + echo '.align 4'; \ echo '.global __dtb_$(*F)_begin'; \ echo '__dtb_$(*F)_begin:'; \ echo '.incbin "$<" '; \
On 09 Dec 2014, at 4:17 PM, Simon Glass sjg@chromium.org wrote:
(sorry, forgot to cc list)
On 9 December 2014 at 07:17, Simon Glass sjg@chromium.org wrote:
Hi,
On 8 December 2014 at 01:54, Duxiaoqiang duxiaoqiang@huawei.com wrote:
Hi Michael,
Thanks for your information.
My working result show that public exponent is not the only problem caused by 64bit alignment, there are also some other problems caused by it, for example: load image after verify step.
If you post your console output then perhaps we might be able to suggest a fix.
May be we should add a patch to cover all 64 bit platform's alignment.
For we need verified boot feature to solve some problems, I also spent some time trying to solve the problem.
But I am not very familiar with uboot FDT'S design, it may spend me long time so not very convenient for me to solve this problem.
So I want to know do you have time to fix this problem recently, and what's your plan.
I haven't tried this on 64-bit ARM. I may be able to do so later in the month.
Thanks very much.
Sincerely Jason
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.
Michael
On 02 Dec 2014, at 12:31 AM, Simon Glass sjg@chromium.org wrote:
+Michael, U-Boot mailing list
Hi,
On 30 November 2014 at 19:26, Duxiaoqiang duxiaoqiang@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
Hi Michael,
On 5 March 2015 at 06:29, Michael van der Westhuizen michael@smart-africa.com wrote:
Resurrecting this old thread…
Jason,
We’re presently getting CONFIG_OF_EMBED up on a 32 bit PPC target and hit a problem that made me think of this thread.
What we’re seeing (in v2014.07) is that the FDT pointer is not necessarily aligned in the wrapper assembly file. We’ve worked around this with the following patch. You may want to try a similar patch to see if it resolves your problem.
This was fixed in mainline around November. You could cherry-pick 5c30bf4 into your branch.
Regards, Simon
Michael
diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib index 072abaa..987298f 100644 --- a/scripts/Makefile.lib +++ b/scripts/Makefile.lib @@ -251,6 +251,7 @@ quiet_cmd_dt_S_dtb= DTB $@ cmd_dt_S_dtb= \ ( \ echo '.section .dtb.init.rodata,"a"'; \
echo '.align 4'; \ echo '.global __dtb_$(*F)_begin'; \ echo '__dtb_$(*F)_begin:'; \ echo '.incbin "$<" '; \On 09 Dec 2014, at 4:17 PM, Simon Glass sjg@chromium.org wrote:
(sorry, forgot to cc list)
On 9 December 2014 at 07:17, Simon Glass sjg@chromium.org wrote:
Hi,
On 8 December 2014 at 01:54, Duxiaoqiang duxiaoqiang@huawei.com wrote:
Hi Michael,
Thanks for your information.
My working result show that public exponent is not the only problem caused by 64bit alignment, there are also some other problems caused by it, for example: load image after verify step.
If you post your console output then perhaps we might be able to suggest a fix.
May be we should add a patch to cover all 64 bit platform's alignment.
For we need verified boot feature to solve some problems, I also spent some time trying to solve the problem.
But I am not very familiar with uboot FDT'S design, it may spend me long time so not very convenient for me to solve this problem.
So I want to know do you have time to fix this problem recently, and what's your plan.
I haven't tried this on 64-bit ARM. I may be able to do so later in the month.
Thanks very much.
Sincerely Jason
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.
Michael
On 02 Dec 2014, at 12:31 AM, Simon Glass sjg@chromium.org wrote:
+Michael, U-Boot mailing list
Hi,
On 30 November 2014 at 19:26, Duxiaoqiang duxiaoqiang@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
participants (2)
-
Michael van der Westhuizen -
Simon Glass