* [U-Boot] Hi Simon, Problems about RSA public exponents for verified boot [not found] <1C178FD3E32FB24C8B1881FDCC155D8F8FAB4C15@SZXEMA502-MBX.china.huawei.com> @ 2014-12-01 22:31 ` Simon Glass 2014-12-04 8:38 ` Michael van der Westhuizen 0 siblings, 1 reply; 6+ messages in thread From: Simon Glass @ 2014-12-01 22:31 UTC (permalink / raw) To: u-boot +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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* [U-Boot] Hi Simon, Problems about RSA public exponents for verified boot 2014-12-01 22:31 ` [U-Boot] Hi Simon, Problems about RSA public exponents for verified boot Simon Glass @ 2014-12-04 8:38 ` Michael van der Westhuizen 2014-12-05 0:06 ` Simon Glass [not found] ` <1C178FD3E32FB24C8B1881FDCC155D8F8FABD326@SZXEMA502-MBX.china.huawei.com> 0 siblings, 2 replies; 6+ messages in thread From: Michael van der Westhuizen @ 2014-12-04 8:38 UTC (permalink / raw) To: u-boot 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* [U-Boot] Hi Simon, Problems about RSA public exponents for verified boot 2014-12-04 8:38 ` Michael van der Westhuizen @ 2014-12-05 0:06 ` Simon Glass [not found] ` <1C178FD3E32FB24C8B1881FDCC155D8F8FABD326@SZXEMA502-MBX.china.huawei.com> 1 sibling, 0 replies; 6+ messages in thread From: Simon Glass @ 2014-12-05 0:06 UTC (permalink / raw) To: u-boot Hi, On 4 December 2014 at 01:38, Michael van der Westhuizen <michael@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@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 > ^ permalink raw reply [flat|nested] 6+ messages in thread
[parent not found: <1C178FD3E32FB24C8B1881FDCC155D8F8FABD326@SZXEMA502-MBX.china.huawei.com>]
[parent not found: <CAPnjgZ1ez20et93KCUTbBPoDdL2JCNRRw0-NrdVH3kRFGmTK6A@mail.gmail.com>]
* [U-Boot] Hi Simon, Problems about RSA public exponents for verified boot [not found] ` <CAPnjgZ1ez20et93KCUTbBPoDdL2JCNRRw0-NrdVH3kRFGmTK6A@mail.gmail.com> @ 2014-12-09 14:17 ` Simon Glass 2015-03-05 13:29 ` Michael van der Westhuizen 0 siblings, 1 reply; 6+ messages in thread From: Simon Glass @ 2014-12-09 14:17 UTC (permalink / raw) To: u-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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* [U-Boot] Hi Simon, Problems about RSA public exponents for verified boot 2014-12-09 14:17 ` Simon Glass @ 2015-03-05 13:29 ` Michael van der Westhuizen 2015-03-05 21:47 ` Simon Glass 0 siblings, 1 reply; 6+ messages in thread From: Michael van der Westhuizen @ 2015-03-05 13:29 UTC (permalink / raw) To: u-boot 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 ^ permalink raw reply related [flat|nested] 6+ messages in thread
* [U-Boot] Hi Simon, Problems about RSA public exponents for verified boot 2015-03-05 13:29 ` Michael van der Westhuizen @ 2015-03-05 21:47 ` Simon Glass 0 siblings, 0 replies; 6+ messages in thread From: Simon Glass @ 2015-03-05 21:47 UTC (permalink / raw) To: u-boot 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 > ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2015-03-05 21:47 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <1C178FD3E32FB24C8B1881FDCC155D8F8FAB4C15@SZXEMA502-MBX.china.huawei.com>
2014-12-01 22:31 ` [U-Boot] Hi Simon, Problems about RSA public exponents for verified boot Simon Glass
2014-12-04 8:38 ` Michael van der Westhuizen
2014-12-05 0:06 ` Simon Glass
[not found] ` <1C178FD3E32FB24C8B1881FDCC155D8F8FABD326@SZXEMA502-MBX.china.huawei.com>
[not found] ` <CAPnjgZ1ez20et93KCUTbBPoDdL2JCNRRw0-NrdVH3kRFGmTK6A@mail.gmail.com>
2014-12-09 14:17 ` Simon Glass
2015-03-05 13:29 ` Michael van der Westhuizen
2015-03-05 21:47 ` Simon Glass
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.