* U-boot [not found] ` <CAPnjgZ2BSCMcN=-3Vr4wcgZgtB5ExdAxDPE2yfQvT5WJTVajbg@mail.gmail.com> @ 2021-07-30 17:34 ` Roman Kopytin 2021-07-30 17:50 ` U-boot Michael Nazzareno Trimarchi 0 siblings, 1 reply; 17+ messages in thread From: Roman Kopytin @ 2021-07-30 17:34 UTC (permalink / raw) To: u-boot; +Cc: Simon Glass Hello, dear U-boot team I have question about your old feature: U-boot patch for adding of the public key to dtb file. https://patchwork.ozlabs.org/project/uboot/patch/1363650725-30459-37-git-send-email-sjg%40chromium.org/ I can’t understand, can we work only with public key? Why do we need to have private key for adding step? In documentation it is not very clear for me. Thanks a lot. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: U-boot 2021-07-30 17:34 ` U-boot Roman Kopytin @ 2021-07-30 17:50 ` Michael Nazzareno Trimarchi 2021-07-31 3:34 ` U-boot Roman Kopytin 0 siblings, 1 reply; 17+ messages in thread From: Michael Nazzareno Trimarchi @ 2021-07-30 17:50 UTC (permalink / raw) To: Roman Kopytin; +Cc: U-Boot-Denx, Simon Glass Hi Román On Fri, Jul 30, 2021, 7:44 PM Roman Kopytin <Roman.Kopytin@kaspersky.com> wrote: > Hello, dear U-boot team > > I have question about your old feature: U-boot patch for adding of the > public key to dtb file. > > https://patchwork.ozlabs.org/project/uboot/patch/1363650725-30459-37-git-send-email-sjg%40chromium.org/ > > I can’t understand, can we work only with public key? Why do we need to > have private key for adding step? > In documentation it is not very clear for me. > You need to sign with private key and keep it secret and local and verify it during booting with public key. Private key is not distributed with the image Michael > Thanks a lot. > > > ^ permalink raw reply [flat|nested] 17+ messages in thread
* RE: U-boot 2021-07-30 17:50 ` U-boot Michael Nazzareno Trimarchi @ 2021-07-31 3:34 ` Roman Kopytin 2021-07-31 6:51 ` U-boot Thomas Perrot 0 siblings, 1 reply; 17+ messages in thread From: Roman Kopytin @ 2021-07-31 3:34 UTC (permalink / raw) To: Michael Nazzareno Trimarchi; +Cc: U-Boot-Denx, Simon Glass Thanks, Michael. Can we sign in the separate state on special server for example? Looks like we can work with public key only in this step. From: Michael Nazzareno Trimarchi <michael@amarulasolutions.com> Sent: Friday, July 30, 2021 8:50 PM To: Roman Kopytin <Roman.Kopytin@kaspersky.com> Cc: U-Boot-Denx <u-boot@lists.denx.de>; Simon Glass <sjg@chromium.org> Subject: Re: U-boot Caution: This is an external email. Be cautious while opening links or attachments. Hi Román On Fri, Jul 30, 2021, 7:44 PM Roman Kopytin <Roman.Kopytin@kaspersky.com<mailto:Roman.Kopytin@kaspersky.com>> wrote: Hello, dear U-boot team I have question about your old feature: U-boot patch for adding of the public key to dtb file. https://patchwork.ozlabs.org/project/uboot/patch/1363650725-30459-37-git-send-email-sjg%40chromium.org/ I can’t understand, can we work only with public key? Why do we need to have private key for adding step? In documentation it is not very clear for me. You need to sign with private key and keep it secret and local and verify it during booting with public key. Private key is not distributed with the image Michael Thanks a lot. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: U-boot 2021-07-31 3:34 ` U-boot Roman Kopytin @ 2021-07-31 6:51 ` Thomas Perrot 2021-07-31 8:26 ` U-boot Roman Kopytin 0 siblings, 1 reply; 17+ messages in thread From: Thomas Perrot @ 2021-07-31 6:51 UTC (permalink / raw) To: Roman Kopytin, Michael Nazzareno Trimarchi; +Cc: U-Boot-Denx, Simon Glass [-- Attachment #1: Type: text/plain, Size: 2393 bytes --] Hi Roman, On Sat, 2021-07-31 at 03:34 +0000, Roman Kopytin wrote: > Thanks, Michael. > Can we sign in the separate state on special server for example? Yes, it possible, there is a step to build and another one to sign, that can be separated. For example, the following command, that build and sign the itb: # build and sign mkimage -D "-I dts -O dtb -p 4096" -f ./foo.its -k ./keys -K ./u- boot.dtb -r ./foo.itb Can be spitted in two: # build uboot-mkimage \ -D "-I dts -O dtb -p 4096" \ -f ./foo.its \ ./foo.itb # sign uboot-mkimage \ -D "-I dts -O dtb -p 4096" -F -k ./keys \ -K ./u-boot.dtb \ -r \ ./foo.itb Then the u-boot*.dtb should contains the pubkey node(s) in the signature node and it can be shared and concatenated to the U-Boot binary: make EXT_DTB="./u-boot.dtb" > Looks like we can work with public key only in this step. The dtb containing the public key(s) is useful to verify the signature at the target boot, or with the tool fit_check_sign to perform an offload checking, for example: fit_check_sign -f ./foo.itb -k ./u-boot.dtb Best regards, Thomas Perrot > > From: Michael Nazzareno Trimarchi <michael@amarulasolutions.com> > Sent: Friday, July 30, 2021 8:50 PM > To: Roman Kopytin <Roman.Kopytin@kaspersky.com> > Cc: U-Boot-Denx <u-boot@lists.denx.de>; Simon Glass <sjg@chromium.org> > Subject: Re: U-boot > > Caution: This is an external email. Be cautious while opening links or > attachments. > > > Hi Román > > > On Fri, Jul 30, 2021, 7:44 PM Roman Kopytin < > Roman.Kopytin@kaspersky.com<mailto:Roman.Kopytin@kaspersky.com>> wrote: > Hello, dear U-boot team > > I have question about your old feature: U-boot patch for adding of the > public key to dtb file. > > https://patchwork.ozlabs.org/project/uboot/patch/1363650725-30459-37-git-send-email-sjg%40chromium.org/ > > I can’t understand, can we work only with public key? Why do we need to > have private key for adding step? > In documentation it is not very clear for me. > > You need to sign with private key and keep it secret and local and > verify it during booting with public key. Private key is not > distributed with the image > > Michael > > > Thanks a lot. > -- Thomas Perrot, Bootlin Embedded Linux and kernel engineering https://bootlin.com [-- Attachment #2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 659 bytes --] ^ permalink raw reply [flat|nested] 17+ messages in thread
* RE: U-boot 2021-07-31 6:51 ` U-boot Thomas Perrot @ 2021-07-31 8:26 ` Roman Kopytin 2021-07-31 16:59 ` U-boot Simon Glass 0 siblings, 1 reply; 17+ messages in thread From: Roman Kopytin @ 2021-07-31 8:26 UTC (permalink / raw) To: Thomas Perrot, Michael Nazzareno Trimarchi; +Cc: U-Boot-Denx, Simon Glass Thank, but my question was about adding of the public key to dtb file without private key. We won't have private key in our side. -----Original Message----- From: Thomas Perrot <thomas.perrot@bootlin.com> Sent: Saturday, July 31, 2021 9:52 AM To: Roman Kopytin <Roman.Kopytin@kaspersky.com>; Michael Nazzareno Trimarchi <michael@amarulasolutions.com> Cc: U-Boot-Denx <u-boot@lists.denx.de>; Simon Glass <sjg@chromium.org> Subject: Re: U-boot Hi Roman, On Sat, 2021-07-31 at 03:34 +0000, Roman Kopytin wrote: > Thanks, Michael. > Can we sign in the separate state on special server for example? Yes, it possible, there is a step to build and another one to sign, that can be separated. For example, the following command, that build and sign the itb: # build and sign mkimage -D "-I dts -O dtb -p 4096" -f ./foo.its -k ./keys -K ./u- boot.dtb -r ./foo.itb Can be spitted in two: # build uboot-mkimage \ -D "-I dts -O dtb -p 4096" \ -f ./foo.its \ ./foo.itb # sign uboot-mkimage \ -D "-I dts -O dtb -p 4096" -F -k ./keys \ -K ./u-boot.dtb \ -r \ ./foo.itb Then the u-boot*.dtb should contains the pubkey node(s) in the signature node and it can be shared and concatenated to the U-Boot binary: make EXT_DTB="./u-boot.dtb" > Looks like we can work with public key only in this step. The dtb containing the public key(s) is useful to verify the signature at the target boot, or with the tool fit_check_sign to perform an offload checking, for example: fit_check_sign -f ./foo.itb -k ./u-boot.dtb Best regards, Thomas Perrot > > From: Michael Nazzareno Trimarchi <michael@amarulasolutions.com> > Sent: Friday, July 30, 2021 8:50 PM > To: Roman Kopytin <Roman.Kopytin@kaspersky.com> > Cc: U-Boot-Denx <u-boot@lists.denx.de>; Simon Glass <sjg@chromium.org> > Subject: Re: U-boot > > Caution: This is an external email. Be cautious while opening links or > attachments. > > > Hi Román > > > On Fri, Jul 30, 2021, 7:44 PM Roman Kopytin < > Roman.Kopytin@kaspersky.com<mailto:Roman.Kopytin@kaspersky.com>> wrote: > Hello, dear U-boot team > > I have question about your old feature: U-boot patch for adding of the > public key to dtb file. > > https://patchwork.ozlabs.org/project/uboot/patch/1363650725-30459-37-g > it-send-email-sjg%40chromium.org/ > > I can’t understand, can we work only with public key? Why do we need > to have private key for adding step? > In documentation it is not very clear for me. > > You need to sign with private key and keep it secret and local and > verify it during booting with public key. Private key is not > distributed with the image > > Michael > > > Thanks a lot. > -- Thomas Perrot, Bootlin Embedded Linux and kernel engineering https://bootlin.com ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: U-boot 2021-07-31 8:26 ` U-boot Roman Kopytin @ 2021-07-31 16:59 ` Simon Glass 2021-08-02 9:00 ` U-boot Rasmus Villemoes 0 siblings, 1 reply; 17+ messages in thread From: Simon Glass @ 2021-07-31 16:59 UTC (permalink / raw) To: Roman Kopytin; +Cc: Thomas Perrot, Michael Nazzareno Trimarchi, U-Boot-Denx Hi Roman, On Sat, 31 Jul 2021 at 02:26, Roman Kopytin <Roman.Kopytin@kaspersky.com> wrote: > > Thank, but my question was about adding of the public key to dtb file without private key. We won't have private key in our side. (please try not to top-post on the mailing list) Presumably this means that you know what the public key is, so one option is to manually add it to the dtb, e.g. in a u-boot.dtsi file for your board. You can see the format of it in the documentation, or just copy what is there when you do the signing. Another option would be to use 'fdtput' to add the various fields in the dtb after building. - Simon > > -----Original Message----- > From: Thomas Perrot <thomas.perrot@bootlin.com> > Sent: Saturday, July 31, 2021 9:52 AM > To: Roman Kopytin <Roman.Kopytin@kaspersky.com>; Michael Nazzareno Trimarchi <michael@amarulasolutions.com> > Cc: U-Boot-Denx <u-boot@lists.denx.de>; Simon Glass <sjg@chromium.org> > Subject: Re: U-boot > > Hi Roman, > > On Sat, 2021-07-31 at 03:34 +0000, Roman Kopytin wrote: > > Thanks, Michael. > > Can we sign in the separate state on special server for example? > > Yes, it possible, there is a step to build and another one to sign, that can be separated. > > For example, the following command, that build and sign the itb: > # build and sign > mkimage -D "-I dts -O dtb -p 4096" -f ./foo.its -k ./keys -K ./u- boot.dtb -r ./foo.itb > > Can be spitted in two: > # build > uboot-mkimage \ > -D "-I dts -O dtb -p 4096" \ > -f ./foo.its \ > ./foo.itb > > # sign > uboot-mkimage \ > -D "-I dts -O dtb -p 4096" -F > -k ./keys \ > -K ./u-boot.dtb \ > -r \ > ./foo.itb > > Then the u-boot*.dtb should contains the pubkey node(s) in the signature node and it can be shared and concatenated to the U-Boot > binary: > > make EXT_DTB="./u-boot.dtb" > > > Looks like we can work with public key only in this step. > > The dtb containing the public key(s) is useful to verify the signature at the target boot, or with the tool fit_check_sign to perform an offload checking, for example: > > fit_check_sign -f ./foo.itb -k ./u-boot.dtb > > Best regards, > Thomas Perrot > > > > > From: Michael Nazzareno Trimarchi <michael@amarulasolutions.com> > > Sent: Friday, July 30, 2021 8:50 PM > > To: Roman Kopytin <Roman.Kopytin@kaspersky.com> > > Cc: U-Boot-Denx <u-boot@lists.denx.de>; Simon Glass <sjg@chromium.org> > > Subject: Re: U-boot > > > > Caution: This is an external email. Be cautious while opening links or > > attachments. > > > > > > Hi Román > > > > > > On Fri, Jul 30, 2021, 7:44 PM Roman Kopytin < > > Roman.Kopytin@kaspersky.com<mailto:Roman.Kopytin@kaspersky.com>> wrote: > > Hello, dear U-boot team > > > > I have question about your old feature: U-boot patch for adding of the > > public key to dtb file. > > > > https://patchwork.ozlabs.org/project/uboot/patch/1363650725-30459-37-g > > it-send-email-sjg%40chromium.org/ > > > > I can’t understand, can we work only with public key? Why do we need > > to have private key for adding step? > > In documentation it is not very clear for me. > > > > You need to sign with private key and keep it secret and local and > > verify it during booting with public key. Private key is not > > distributed with the image > > > > Michael > > > > > > Thanks a lot. > > > > -- > Thomas Perrot, Bootlin > Embedded Linux and kernel engineering > https://bootlin.com > ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: U-boot 2021-07-31 16:59 ` U-boot Simon Glass @ 2021-08-02 9:00 ` Rasmus Villemoes 2021-08-02 9:25 ` U-boot Roman Kopytin 0 siblings, 1 reply; 17+ messages in thread From: Rasmus Villemoes @ 2021-08-02 9:00 UTC (permalink / raw) To: Simon Glass, Roman Kopytin Cc: Thomas Perrot, Michael Nazzareno Trimarchi, U-Boot-Denx, Alex Kiernan On 31/07/2021 18.59, Simon Glass wrote: > Hi Roman, > > On Sat, 31 Jul 2021 at 02:26, Roman Kopytin <Roman.Kopytin@kaspersky.com> wrote: >> >> Thank, but my question was about adding of the public key to dtb file without private key. We won't have private key in our side. > > (please try not to top-post on the mailing list) > > Presumably this means that you know what the public key is, so one > option is to manually add it to the dtb, e.g. in a u-boot.dtsi file > for your board. You can see the format of it in the documentation, or > just copy what is there when you do the signing. > I sent https://lore.kernel.org/u-boot/20200211094818.14219-3-rasmus.villemoes@prevas.dk/ 1.5 years ago. Roman, is it something like that you need? We've used that patch/tool internally ever since. > Another option would be to use 'fdtput' to add the various fields in > the dtb after building. Yes, but that, or the .dtsi approach, requires figuring just exactly what those fields are supposed to be. And even if one could "reverse engineer" that and implement the math separately in another tool, it's much better to utilize the same code which "mkimage proper" would use, since there's less risk of messing up endianness etc., and only one place to fix bugs. Rasmus ^ permalink raw reply [flat|nested] 17+ messages in thread
* RE: U-boot 2021-08-02 9:00 ` U-boot Rasmus Villemoes @ 2021-08-02 9:25 ` Roman Kopytin 2021-08-02 9:37 ` U-boot Rasmus Villemoes 0 siblings, 1 reply; 17+ messages in thread From: Roman Kopytin @ 2021-08-02 9:25 UTC (permalink / raw) To: Rasmus Villemoes, Simon Glass Cc: Thomas Perrot, Michael Nazzareno Trimarchi, U-Boot-Denx, Alex Kiernan Thanks a lot! Yes, looks like using of the 'fdtput' is not very safety for me. As I understood I need to use "fdt_add_pubkey" tool with CMD (example): ./ fdt_add_pubkey -a rsa2048 -k <keydir> -n <keyname> -r <conf|image> my_file.dtb -r <conf|image> is the same as for mkimage? As I remember we can use -r w/o any values in mkimage. -----Original Message----- From: Rasmus Villemoes <rasmus.villemoes@prevas.dk> Sent: Monday, August 2, 2021 12:00 PM To: Simon Glass <sjg@chromium.org>; Roman Kopytin <Roman.Kopytin@kaspersky.com> Cc: Thomas Perrot <thomas.perrot@bootlin.com>; Michael Nazzareno Trimarchi <michael@amarulasolutions.com>; U-Boot-Denx <u-boot@lists.denx.de>; Alex Kiernan <alex.kiernan@gmail.com> Subject: Re: U-boot Caution: This is an external email. Be cautious while opening links or attachments. On 31/07/2021 18.59, Simon Glass wrote: > Hi Roman, > > On Sat, 31 Jul 2021 at 02:26, Roman Kopytin <Roman.Kopytin@kaspersky.com> wrote: >> >> Thank, but my question was about adding of the public key to dtb file without private key. We won't have private key in our side. > > (please try not to top-post on the mailing list) > > Presumably this means that you know what the public key is, so one > option is to manually add it to the dtb, e.g. in a u-boot.dtsi file > for your board. You can see the format of it in the documentation, or > just copy what is there when you do the signing. > I sent https://lore.kernel.org/u-boot/20200211094818.14219-3-rasmus.villemoes@prevas.dk/ 1.5 years ago. Roman, is it something like that you need? We've used that patch/tool internally ever since. > Another option would be to use 'fdtput' to add the various fields in > the dtb after building. Yes, but that, or the .dtsi approach, requires figuring just exactly what those fields are supposed to be. And even if one could "reverse engineer" that and implement the math separately in another tool, it's much better to utilize the same code which "mkimage proper" would use, since there's less risk of messing up endianness etc., and only one place to fix bugs. Rasmus ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: U-boot 2021-08-02 9:25 ` U-boot Roman Kopytin @ 2021-08-02 9:37 ` Rasmus Villemoes 2021-08-02 9:55 ` U-boot Roman Kopytin ` (2 more replies) 0 siblings, 3 replies; 17+ messages in thread From: Rasmus Villemoes @ 2021-08-02 9:37 UTC (permalink / raw) To: Roman Kopytin, Simon Glass Cc: Thomas Perrot, Michael Nazzareno Trimarchi, U-Boot-Denx, Alex Kiernan On 02/08/2021 11.25, Roman Kopytin wrote: > Thanks a lot! > Yes, looks like using of the 'fdtput' is not very safety for me. > As I understood I need to use "fdt_add_pubkey" tool with CMD (example): > ./ fdt_add_pubkey -a rsa2048 -k <keydir> -n <keyname> -r <conf|image> my_file.dtb > > -r <conf|image> is the same as for mkimage? As I remember we can use -r w/o any values in mkimage. Yes, that's very close to what our Yocto recipe currently does: for b in ${KERNEL_PUBLIC_KEYS} ; do fdt_add_pubkey -a 'sha1,rsa2048' -k "${KERNEL_SIGNING_DIR}" -n "$b" \ -r conf $dtb done I doubt that old patch applies nowadays, I've only forward-ported it to 2020.04 internally. As to Simon's old question of whether it could be done in mkimage with a new flag: I'd really prefer not to, mkimage is already an incoherent collection of tools that do very different things with different flags. Having a flag that says "create and sign this FIT image, and as a side effect update $this dtb $overhere with the corresponding public key mangled appropriately, oh, and btw, _only_ do that side effect" is a non-starter. Rasmus ^ permalink raw reply [flat|nested] 17+ messages in thread
* RE: U-boot 2021-08-02 9:37 ` U-boot Rasmus Villemoes @ 2021-08-02 9:55 ` Roman Kopytin 2021-08-02 11:08 ` U-boot Rasmus Villemoes 2021-08-02 19:20 ` U-boot Simon Glass [not found] ` <4ba7d9814f544d56b32589e86a5e0617@kaspersky.com> 2 siblings, 1 reply; 17+ messages in thread From: Roman Kopytin @ 2021-08-02 9:55 UTC (permalink / raw) To: Rasmus Villemoes, Simon Glass Cc: Thomas Perrot, Michael Nazzareno Trimarchi, U-Boot-Denx, Alex Kiernan Yes, I don't see this tool in master branch. May be I will take code and build this tool. Do you have a plan for sharing it in repo? -----Original Message----- From: Rasmus Villemoes <rasmus.villemoes@prevas.dk> Sent: Monday, August 2, 2021 12:37 PM To: Roman Kopytin <Roman.Kopytin@kaspersky.com>; Simon Glass <sjg@chromium.org> Cc: Thomas Perrot <thomas.perrot@bootlin.com>; Michael Nazzareno Trimarchi <michael@amarulasolutions.com>; U-Boot-Denx <u-boot@lists.denx.de>; Alex Kiernan <alex.kiernan@gmail.com> Subject: Re: U-boot Caution: This is an external email. Be cautious while opening links or attachments. On 02/08/2021 11.25, Roman Kopytin wrote: > Thanks a lot! > Yes, looks like using of the 'fdtput' is not very safety for me. > As I understood I need to use "fdt_add_pubkey" tool with CMD (example): > ./ fdt_add_pubkey -a rsa2048 -k <keydir> -n <keyname> -r <conf|image> > my_file.dtb > > -r <conf|image> is the same as for mkimage? As I remember we can use -r w/o any values in mkimage. Yes, that's very close to what our Yocto recipe currently does: for b in ${KERNEL_PUBLIC_KEYS} ; do fdt_add_pubkey -a 'sha1,rsa2048' -k "${KERNEL_SIGNING_DIR}" -n "$b" \ -r conf $dtb done I doubt that old patch applies nowadays, I've only forward-ported it to 2020.04 internally. As to Simon's old question of whether it could be done in mkimage with a new flag: I'd really prefer not to, mkimage is already an incoherent collection of tools that do very different things with different flags. Having a flag that says "create and sign this FIT image, and as a side effect update $this dtb $overhere with the corresponding public key mangled appropriately, oh, and btw, _only_ do that side effect" is a non-starter. Rasmus ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: U-boot 2021-08-02 9:55 ` U-boot Roman Kopytin @ 2021-08-02 11:08 ` Rasmus Villemoes 2021-08-02 11:18 ` U-boot Roman Kopytin 2021-08-02 12:35 ` U-boot Roman Kopytin 0 siblings, 2 replies; 17+ messages in thread From: Rasmus Villemoes @ 2021-08-02 11:08 UTC (permalink / raw) To: Roman Kopytin, Simon Glass Cc: Thomas Perrot, Michael Nazzareno Trimarchi, U-Boot-Denx, Alex Kiernan On 02/08/2021 11.55, Roman Kopytin wrote: > Yes, I don't see this tool in master branch. > May be I will take code and build this tool. > > Do you have a plan for sharing it in repo? Well, the repo for "sharing" this would/should be upstream U-Boot, and if there's sufficient interest I'll rebase and resend - though I can't promise any time frame, as there's a lot of other things on my plate. If you have the time, feel free to take the code and submit it yourself. Rasmus ^ permalink raw reply [flat|nested] 17+ messages in thread
* RE: U-boot 2021-08-02 11:08 ` U-boot Rasmus Villemoes @ 2021-08-02 11:18 ` Roman Kopytin 2021-08-02 12:35 ` U-boot Roman Kopytin 1 sibling, 0 replies; 17+ messages in thread From: Roman Kopytin @ 2021-08-02 11:18 UTC (permalink / raw) To: Rasmus Villemoes, Simon Glass Cc: Thomas Perrot, Michael Nazzareno Trimarchi, U-Boot-Denx, Alex Kiernan Thanks, I have good result with tool. Ok, I will check my tasks and will try to add this tool. -----Original Message----- From: Rasmus Villemoes <rasmus.villemoes@prevas.dk> Sent: Monday, August 2, 2021 2:09 PM To: Roman Kopytin <Roman.Kopytin@kaspersky.com>; Simon Glass <sjg@chromium.org> Cc: Thomas Perrot <thomas.perrot@bootlin.com>; Michael Nazzareno Trimarchi <michael@amarulasolutions.com>; U-Boot-Denx <u-boot@lists.denx.de>; Alex Kiernan <alex.kiernan@gmail.com> Subject: Re: U-boot Caution: This is an external email. Be cautious while opening links or attachments. On 02/08/2021 11.55, Roman Kopytin wrote: > Yes, I don't see this tool in master branch. > May be I will take code and build this tool. > > Do you have a plan for sharing it in repo? Well, the repo for "sharing" this would/should be upstream U-Boot, and if there's sufficient interest I'll rebase and resend - though I can't promise any time frame, as there's a lot of other things on my plate. If you have the time, feel free to take the code and submit it yourself. Rasmus ^ permalink raw reply [flat|nested] 17+ messages in thread
* RE: U-boot 2021-08-02 11:08 ` U-boot Rasmus Villemoes 2021-08-02 11:18 ` U-boot Roman Kopytin @ 2021-08-02 12:35 ` Roman Kopytin 1 sibling, 0 replies; 17+ messages in thread From: Roman Kopytin @ 2021-08-02 12:35 UTC (permalink / raw) To: Rasmus Villemoes, Simon Glass Cc: Thomas Perrot, Michael Nazzareno Trimarchi, U-Boot-Denx, Alex Kiernan Hi, dear U-boot team Is it correct repo git://git.qemu.org/u-boot ? We have it as our upstream. -----Original Message----- From: Roman Kopytin Sent: Monday, August 2, 2021 2:19 PM To: 'Rasmus Villemoes' <rasmus.villemoes@prevas.dk>; Simon Glass <sjg@chromium.org> Cc: Thomas Perrot <thomas.perrot@bootlin.com>; Michael Nazzareno Trimarchi <michael@amarulasolutions.com>; U-Boot-Denx <u-boot@lists.denx.de>; Alex Kiernan <alex.kiernan@gmail.com> Subject: RE: U-boot Thanks, I have good result with tool. Ok, I will check my tasks and will try to add this tool. -----Original Message----- From: Rasmus Villemoes <rasmus.villemoes@prevas.dk> Sent: Monday, August 2, 2021 2:09 PM To: Roman Kopytin <Roman.Kopytin@kaspersky.com>; Simon Glass <sjg@chromium.org> Cc: Thomas Perrot <thomas.perrot@bootlin.com>; Michael Nazzareno Trimarchi <michael@amarulasolutions.com>; U-Boot-Denx <u-boot@lists.denx.de>; Alex Kiernan <alex.kiernan@gmail.com> Subject: Re: U-boot Caution: This is an external email. Be cautious while opening links or attachments. On 02/08/2021 11.55, Roman Kopytin wrote: > Yes, I don't see this tool in master branch. > May be I will take code and build this tool. > > Do you have a plan for sharing it in repo? Well, the repo for "sharing" this would/should be upstream U-Boot, and if there's sufficient interest I'll rebase and resend - though I can't promise any time frame, as there's a lot of other things on my plate. If you have the time, feel free to take the code and submit it yourself. Rasmus ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: U-boot 2021-08-02 9:37 ` U-boot Rasmus Villemoes 2021-08-02 9:55 ` U-boot Roman Kopytin @ 2021-08-02 19:20 ` Simon Glass [not found] ` <4ba7d9814f544d56b32589e86a5e0617@kaspersky.com> 2 siblings, 0 replies; 17+ messages in thread From: Simon Glass @ 2021-08-02 19:20 UTC (permalink / raw) To: Rasmus Villemoes Cc: Roman Kopytin, Thomas Perrot, Michael Nazzareno Trimarchi, U-Boot-Denx, Alex Kiernan Hi Rasmus, On Mon, 2 Aug 2021 at 03:37, Rasmus Villemoes <rasmus.villemoes@prevas.dk> wrote: > > On 02/08/2021 11.25, Roman Kopytin wrote: > > Thanks a lot! > > Yes, looks like using of the 'fdtput' is not very safety for me. > > As I understood I need to use "fdt_add_pubkey" tool with CMD (example): > > ./ fdt_add_pubkey -a rsa2048 -k <keydir> -n <keyname> -r <conf|image> my_file.dtb > > > > -r <conf|image> is the same as for mkimage? As I remember we can use -r w/o any values in mkimage. > > Yes, that's very close to what our Yocto recipe currently does: > > for b in ${KERNEL_PUBLIC_KEYS} ; do > fdt_add_pubkey -a 'sha1,rsa2048' -k > "${KERNEL_SIGNING_DIR}" -n "$b" \ > -r conf $dtb > done > > I doubt that old patch applies nowadays, I've only forward-ported it to > 2020.04 internally. > > As to Simon's old question of whether it could be done in mkimage with a > new flag: I'd really prefer not to, mkimage is already an incoherent > collection of tools that do very different things with different flags. > Having a flag that says "create and sign this FIT image, and as a side > effect update $this dtb $overhere with the corresponding public key > mangled appropriately, oh, and btw, _only_ do that side effect" is a > non-starter. I missed that comment at the time...I think this tool is useful though. The series is marked as deferred in patchwork, probably because the thread died. How about reposting it? Regards, Simon ^ permalink raw reply [flat|nested] 17+ messages in thread
[parent not found: <4ba7d9814f544d56b32589e86a5e0617@kaspersky.com>]
* Re: U-boot [not found] ` <4ba7d9814f544d56b32589e86a5e0617@kaspersky.com> @ 2021-11-10 19:37 ` Simon Glass 0 siblings, 0 replies; 17+ messages in thread From: Simon Glass @ 2021-11-10 19:37 UTC (permalink / raw) To: Roman Kopytin; +Cc: Rasmus Villemoes, U-Boot Mailing List Hi Roman, see signature.txt : - required: If present this indicates that the key must be verified for the image / configuration to be considered valid. Only required keys are normally verified by the FIT image booting algorithm. Valid values are "image" to force verification of all images, and "conf" to force verification of the selected configuration (which then relies on hashes in the images to verify those). Regards, Simon On Wed, 10 Nov 2021 at 04:20, Roman Kopytin <Roman.Kopytin@kaspersky.com> wrote: > > Hi, Rasmus and Simon > I need more details about -r <conf|image> for fdt_add_pubkey. > I need to add small help for tool, please provide details. > > -----Original Message----- > From: Rasmus Villemoes <rasmus.villemoes@prevas.dk> > Sent: Monday, August 2, 2021 12:37 PM > To: Roman Kopytin <Roman.Kopytin@kaspersky.com>; Simon Glass <sjg@chromium.org> > Cc: Thomas Perrot <thomas.perrot@bootlin.com>; Michael Nazzareno Trimarchi <michael@amarulasolutions.com>; U-Boot-Denx <u-boot@lists.denx.de>; Alex Kiernan <alex.kiernan@gmail.com> > Subject: Re: U-boot > > Caution: This is an external email. Be cautious while opening links or attachments. > > > > On 02/08/2021 11.25, Roman Kopytin wrote: > > Thanks a lot! > > Yes, looks like using of the 'fdtput' is not very safety for me. > > As I understood I need to use "fdt_add_pubkey" tool with CMD (example): > > ./ fdt_add_pubkey -a rsa2048 -k <keydir> -n <keyname> -r <conf|image> > > my_file.dtb > > > > -r <conf|image> is the same as for mkimage? As I remember we can use -r w/o any values in mkimage. > > Yes, that's very close to what our Yocto recipe currently does: > > for b in ${KERNEL_PUBLIC_KEYS} ; do > fdt_add_pubkey -a 'sha1,rsa2048' -k "${KERNEL_SIGNING_DIR}" -n "$b" \ > -r conf $dtb > done > > I doubt that old patch applies nowadays, I've only forward-ported it to > 2020.04 internally. > > As to Simon's old question of whether it could be done in mkimage with a new flag: I'd really prefer not to, mkimage is already an incoherent collection of tools that do very different things with different flags. > Having a flag that says "create and sign this FIT image, and as a side effect update $this dtb $overhere with the corresponding public key mangled appropriately, oh, and btw, _only_ do that side effect" is a non-starter. > > Rasmus ^ permalink raw reply [flat|nested] 17+ messages in thread
* U-Boot @ 2005-11-16 0:15 mcnernbm 2005-11-16 1:06 ` U-Boot Wolfgang Denk 0 siblings, 1 reply; 17+ messages in thread From: mcnernbm @ 2005-11-16 0:15 UTC (permalink / raw) To: linuxppc-embedded [-- Attachment #1: Type: text/plain, Size: 220 bytes --] I have a question about U-Boot. I have a board with no flash capability at all. Will u-boot work on a xilinx board with no flash and only sdram? Can uboot be downloaded into sdram and used to boot linux? Thanks Brett [-- Attachment #2: Type: text/html, Size: 361 bytes --] ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: U-Boot 2005-11-16 0:15 U-Boot mcnernbm @ 2005-11-16 1:06 ` Wolfgang Denk 0 siblings, 0 replies; 17+ messages in thread From: Wolfgang Denk @ 2005-11-16 1:06 UTC (permalink / raw) To: mcnernbm; +Cc: linuxppc-embedded In message <OF3D06561E.1EB2655E-ON852570BB.00015870-852570BB.00016F3F@notes.udayton.edu> you wrote: > > I have a question about U-Boot. I have a board with no flash capability > at all. Will u-boot work on a xilinx board with no flash and only sdram? > Can uboot be downloaded into sdram and used to boot linux? > Thanks > Brett > --=_alternative 00016F3D852570BB_= > Content-Type: text/html; charset="US-ASCII" One questions, three goof-ups. 1) This is the linuxppc-embedded list. U-Boot related questions are off topic here and should be posted to u-boot-users instead. 2) The answers to your questions are "yes" and "yes", but you posted without reading the FAQ. See especially http://www.denx.de/wiki/view/DULG/CanUBootBeConfiguredSuchThatItCanBeStartedInRAM 3) Please don't post HTML to public mailing lists. Best regards, Wolfgang Denk -- Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de Today is the yesterday you worried about tomorrow. ^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2021-11-10 19:37 UTC | newest] Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <25743c08c4b34f9791e39e687399f802@kaspersky.com> [not found] ` <CAPnjgZ2BSCMcN=-3Vr4wcgZgtB5ExdAxDPE2yfQvT5WJTVajbg@mail.gmail.com> 2021-07-30 17:34 ` U-boot Roman Kopytin 2021-07-30 17:50 ` U-boot Michael Nazzareno Trimarchi 2021-07-31 3:34 ` U-boot Roman Kopytin 2021-07-31 6:51 ` U-boot Thomas Perrot 2021-07-31 8:26 ` U-boot Roman Kopytin 2021-07-31 16:59 ` U-boot Simon Glass 2021-08-02 9:00 ` U-boot Rasmus Villemoes 2021-08-02 9:25 ` U-boot Roman Kopytin 2021-08-02 9:37 ` U-boot Rasmus Villemoes 2021-08-02 9:55 ` U-boot Roman Kopytin 2021-08-02 11:08 ` U-boot Rasmus Villemoes 2021-08-02 11:18 ` U-boot Roman Kopytin 2021-08-02 12:35 ` U-boot Roman Kopytin 2021-08-02 19:20 ` U-boot Simon Glass [not found] ` <4ba7d9814f544d56b32589e86a5e0617@kaspersky.com> 2021-11-10 19:37 ` U-boot Simon Glass 2005-11-16 0:15 U-Boot mcnernbm 2005-11-16 1:06 ` U-Boot Wolfgang Denk
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.