
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-sen...
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.

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-sen...
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.

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.commailto: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-sen...
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.

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.commailto: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-sen...
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.

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.commailto: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

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.commailto: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

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@preva... 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

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@preva... 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

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

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

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

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

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

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
participants (5)
-
Michael Nazzareno Trimarchi
-
Rasmus Villemoes
-
Roman Kopytin
-
Simon Glass
-
Thomas Perrot