* 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
* 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@lists.denx.de; +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
* 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
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.