[U-Boot] Hash and crypto accelerator uclasses

[Rick Altherr]

I started looking into the Aspeed AST2400/2500 Hash and Crypto Engine
(HACE) because I'm annoyed by the slight delay during FIT hash
calculation.  HACE is a single device that does hashing, DES/AES, and
RSA in either immediate mode or via a single command queue.

I looked at drivers/crypto/fsl which supports their CAAM device and
has a very similar architecture.  There they register a UCLASS_MOD_EXP
driver for the RSA portion and have a separate legacy driver that
implements the hw_hash methods.  Does making a new uclass for hash
accelerators make sense or is it better to have a single crypto uclass
that handles both hashing and RSA?

From a device tree standpoint, having a single node for HACE is
cleaner and more accurately represents the hardware.  I could treat it
as a multi-function device and add child nodes for hash and rsa but
that is bleeding an implementation detail into the device tree.

Linux deals with this by having drivers register individual algorithms
with the crypto framework during probe.  I like this approach but it
feels oddly out of place in U-Boot's driver model where iterating over
the devices in a uclass is common.  Is this pattern being
intentionally avoided in U-Boot?

Rick
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 13/17] aspeed: Add support for Clocks needed by MACs

[Rick Altherr]

+Joel

On Mon, Mar 20, 2017 at 10:52 AM, Maxim Sloyko  wrote:
>
>
> On Mon, Mar 20, 2017 at 10:30 AM, Tom Rini  wrote:
>>
>> On Mon, Mar 20, 2017 at 10:24:20AM -0700, Maxim Sloyko wrote:
>> > On Sun, Mar 19, 2017 at 9:42 AM, Tom Rini  wrote:
>> >
>> > > On Thu, Mar 16, 2017 at 02:36:20PM -0700, Maxim Sloyko wrote:
>> > > > Add support for clocks needed by MACs to ast2500 clock driver.
>> > > > The clocks are D2-PLL, which is used by both MACs and PCLK_MAC1 and
>> > > > PCLK_MAC2 for MAC1 and MAC2 respectively.
>> > > >
>> > > > The rate of D2-PLL is hardcoded to 250MHz -- the value used in
>> > > > Aspeed
>> > > > SDK. It is not entirely clear from the datasheet how this clock is
>> > > > used
>> > > > by MACs, so not clear if the rate would ever need to be different.
>> > > > So,
>> > > > for now, hardcoding it is probably safer.
>> > > >
>> > > > The rate of PCLK_MAC{1,2} is chosen based on MAC speed selected
>> > > > through
>> > > > hardware strapping.
>> > > >
>> > > > So, the network driver would only need to enable these clocks, no
>> > > > need
>> > > > to configure the rate.
>> > > >
>> > > > Signed-off-by: Maxim Sloyko 
>> > > > ---
>> > > >
>> > > >  arch/arm/dts/ast2500-u-boot.dtsi   |   8 +
>> > > >  arch/arm/include/asm/arch-aspeed/scu_ast2500.h |  62 +-
>> > > >  drivers/clk/aspeed/clk_ast2500.c   | 265
>> > > ++---
>> > > >  include/dt-bindings/clock/ast2500-scu.h|   2 +
>> > > >  4 files changed, 304 insertions(+), 33 deletions(-)
>> > > >
>> > > > diff --git a/arch/arm/dts/ast2500-u-boot.dtsi
>> > > b/arch/arm/dts/ast2500-u-boot.dtsi
>> > > > index faeeec1be4..f826646095 100644
>> > > > --- a/arch/arm/dts/ast2500-u-boot.dtsi
>> > > > +++ b/arch/arm/dts/ast2500-u-boot.dtsi
>> > > > @@ -61,3 +61,11 @@
>> > > >   };
>> > > >   };
>> > > >  };
>> > > > +
>> > > > + {
>> > > > + clocks = < PCLK_MAC1>, < PLL_D2PLL>;
>> > > > +};
>> > > > +
>> > > > + {
>> > > > + clocks = < PCLK_MAC2>, < PLL_D2PLL>;
>> > > > +};
>> > >
>> > > Why is this here and not in the main dts file?  The -u-boot.dtsi is
>> > > for
>> > > stuff that's not appropriate in the upstream dts file.  Thanks!
>> >
>> > There is no clock driver for this part in mainline Linux Kernel yet and
>> > I
>> > don't know how it will end up being configured. I suspect that they
>> > might
>> > not use the same bindings though.
>> >
>> > Should I put this into board specific dts?
>>
>> So this applies to a lot of parts of the series here.  What we don't
>> want to do is have places where the DTS here diverges from the Linux
>> kernel DTS and we don't reconcile them.  If the relevant Linux drivers
>> are not in mainline, are they at least in linux-next or otherwise
>> submitted to the relevant subtrees?
>
>
> No, as far as I know, maybe Rick (cc'ed) knows what is the plan there.
>
> I'm not really working on the linux driver and it's outside of my control.
>

Looks like the Aspeed SDK version of U-Boot was configuring D2PLL as
part of platform_g5.S
(https://github.com/openbmc/u-boot/blob/v2016.07-aspeed-openbmc/arch/arm/mach-aspeed/platform_g5.S).
OpenBMC kernel doesn't seem to have any clock drivers for these PLLs.
I assume that since they were enabled by U-Boot, the ftgmac100 driver
doesn't need to do anything for it to work.  It should be
straightforward to follow the pattern of the other clock drivers in
https://github.com/openbmc/linux/blob/dev-4.7/arch/arm/boot/dts/aspeed-g5.dtsi
and create a new driver for D2PLL.

> I can change network driver, so that it does not use this DT configuration
> and either hard code clock config into it, or configure it's clocks in board
> specific file -- would that be more acceptable?
>
>>
>>
>> --
>> Tom
>
>
>
>
> --
> Maxim Sloyko
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] Complete verified uboot example

[Rick Altherr]

I've been swamped this week.  I hope to pick this up with you next week.

On Tue, Feb 28, 2017 at 4:06 PM, Ron Brash <ron.br...@gmail.com> wrote:
> Hello,
>
> Here is a list of things I have tried:  The raw zImage (which is compressed
> with XZ), various addresses from indeed load address 0x2300, entry at
> 0x23008000 (and the same), I've tried setting the FTD address since it sets
> itself neatly at 0x22f and change, which will probably get itself clobbered.
>
> I've tried playing with the "magic" variables of ftdaddr, loadaddr, and
> verify.  No luck other than a few loops, hangs and illegitimate instructions
> being executed.
>
> Something is missing from my system, documentation or more and it appears to
> be uboot and/or the fit format + FDT/DTBs.
>
> Is there a magic formula?  Before FIT I could just copy my kernel to 0x22...
> and my DTB to another address that wouldn't be clobbered, use bootm and
> everything would work given I set it to a uImage.
>
> Question, does the FDT need a load address specified as well?  Why does the
> documentation use all 0's?  Usually, all zeros is either an example, or will
> be inherit some address from a variable? (perhaps this is not obviously
> documented).
>
>
>
>
> On 28 February 2017 at 16:51, Rick Altherr <ralth...@google.com> wrote:
>>
>> I've never seen the kernel load address (the start address for copying
>> the kernel image into RAM) being the same as the entrypoint address
>> (where U-Boot jumps to begin executing the kernel).  I'd expect the
>> load address to be 0x2300.
>>
>> It looks like you are converting the zImage into a U-Boot legacy image
>> and then storing the legacy image in the FIT.  Don't do that.  Store
>> the zImage in the FIT directly.
>>
>> On Tue, Feb 28, 2017 at 11:09 AM, Ron Brash <ron.br...@gmail.com> wrote:
>> > Hello,
>> >
>> > Still for some reason - there is an issue with booting from the FIT.
>> > With a
>> > version of Uboot without the FIT related CONFIGs enabled; everything
>> > works.
>> >
>> > Here is me taking my zImage and converting it to a u-image ( I am not
>> > sure
>> > on the addresses)
>> >
>> > mkimage -A arm -O linux -C none -T kernel -a 0x23008000 -e 0x23008000 -n
>> > linux-4.4.36b \
>> > -d $(KDIR)/zImage $(BIN_DIR)/$(IMG_PREFIX)-zImage-nDTB2
>> >
>> >
>> > My .its:
>> >
>> > /dts-v1/;
>> > /{
>> > description = "Configuration to load a Basic Kernel";
>> > #address-cells = <1>;
>> > images {
>> > linux_kernel@1 {
>> > description = "Linux zImage";
>> > data =
>> >
>> > /incbin/("../../../../bin/targets/myboard/legacy/myboard-legacy-zImage-nDTB2");
>> > type = "kernel";
>> > arch = "arm";
>> > os = "linux";
>> > compression = "none";
>> > load =  <0x23008000>;
>> > entry = <0x23008000>;
>> > kernel-version = <1>;
>> > hash@1 {
>> > algo = "sha256";
>> > };
>> > };
>> > fdt@1 {
>> > description = "FDT blob";
>> > data = /incbin/("../../../../bin/targets/myboard/legacy/myboard.dtb");
>> > type = "flat_dt";
>> > arch = "arm";
>> > compression = "none";
>> > load =  <0x2800>;
>> > fdt-version = <1>;
>> > hash@1{
>> > algo = "sha256";
>> > };
>> > };
>> > };
>> > configurations {
>> > default = "config@1";
>> > config@1{
>> > description = "Plain Linux";
>> > kernel = "linux_kernel@1";
>> > fdt = "fdt@1";
>> > signature@1{
>> > algo = "sha256,rsa2048";
>> > key-name-hint = "dev_key";
>> > sign-images = "fdt", "kernel";
>> > };
>> > };
>> > };
>> > };
>> >
>> >
>> > Then
>> >
>> >
>> > set -ex
>> > key_dir="/tmp/keys"
>> > key_name="dev_key"
>> >
>> > rm -rf ${FIT_IMG}
>> > rm -rf ${key_dir}
>> > mkdir ${key_dir}
>> > rootdir="/home/dev/usr"
>> >
>> > MKIMG="${rootdir}/lede/staging_dir/host/bin/mkimage"
>> > DTC="/usr/bin/dtc"
>> > CPP="/usr/bin/cpp"
>> > OPENSSL="/usr

Re: [U-Boot] Complete verified uboot example

[Rick Altherr]

line image address =
> 0x2200
> ## Loading kernel from FIT Image at 2200 ...
> No configuration specified, trying default...
> Found default configuration: 'config@1'
>Using 'config@1' configuration
>Trying 'linux_kernel@1' kernel subimage
>  Description:  Linux zImage
>  Type: Kernel Image
>  Compression:  uncompressed
>  Data Start:   0x22dc
>  Data Size:1465544 Bytes = 1.4 MiB
>  Architecture: ARM
>  OS:   Linux
>  Load Address: 0x23008000
>  Entry Point:  0x23008000
>  Hash node:'hash@1'
>  Hash algo:sha256
>  Hash value:
> 52f8048436c3f62d9108957cb4f6f7d4e58c8c9931d68ea6f0121f4c661c7ffe
>  Hash len: 32
>Verifying Hash Integrity ... sha256+ OK
>kernel data at 0x22dc, len = 0x00165cc8 (1465544)
> *  ramdisk: using config 'config@1' from image at 0x2200
> *  ramdisk: no 'ramdisk' in config
> *  fdt: using config 'config@1' from image at 0x2200
> ## Checking for 'FDT'/'FDT Image' at 2200
> ## Loading fdt from FIT Image at 2200 ...
>Using 'config@1' configuration
>Trying 'fdt@1' fdt subimage
>  Description:  FDT blob
>  Type: Flat Device Tree
>  Compression:  uncompressed
>  Data Start:   0x22165ea4
>  Data Size:21681 Bytes = 21.2 KiB
>  Architecture: ARM
>  Hash node:'hash@1'
>  Hash algo:sha256
>  Hash value:
> c7f32d039871d858dda8d397c3b6a685bc914c78cf70f03d1860f61ecfe9c689
>  Hash len: 32
>Verifying Hash Integrity ... sha256+ OK
>Loading fdt from 0x22165ea4 to 0x2800
>Booting using the fdt blob at 0x2800
>of_flat_tree at 0x2800 size 0x54b1
> Initial value for argc=3
> Final value for argc=3
>Loading Kernel Image ... OK
> CACHE: Misaligned operation at range [23008000, 2316dcc8]
>kernel loaded at 0x23008000, end = 0x2316dcc8
> using: FDT
> ## initrd_high = 0x2400, copy_to_ram = 1
>ramdisk load start = 0x, ramdisk load end = 0x
> ## device tree at 2800 ... 280054b0 (len=33969 [0x84B1])
>Loading Device Tree to 23f08000, end 23f104b0 ... OK
> Initial value for argc=3
> Final value for argc=3
> ## Transferring control to Linux (at address 23008000)...
>
> Starting kernel ...
>
> undefined instruction
> pc : [<23008028>]  lr : [<23f44ca4>]
> reloc pc : [<20fc3028>]lr : [<21effca4>]
> sp : 23f11980  ip : 23f9472c fp : 
> r10: 23f1e61c  r9 : 23f17ef0 r8 : 23f4585c
> r7 :   r6 : 23008000 r5 : 23f9b0f4  r4 : 0081
> r3 : 54b1  r2 : 23f08000 r1 : 0658  r0 : 2390
> Flags: nZCv  IRQs off  FIQs off  Mode SVC_32
> Resetting CPU ...
>
> With iminfo:
>
> #> cp.b 0xD0084000 0x2200 0x186A00
> #> iminfo
>
> ## Checking Image at 2200 ...
>FIT image found
>FIT description: Configuration to load a Basic Kernel
> Image 0 (linux_kernel@1)
>  Description:  Linux zImage
>  Type: Kernel Image
>  Compression:  uncompressed
>  Data Start:   0x22dc
>  Data Size:1465544 Bytes = 1.4 MiB
>  Architecture: ARM
>  OS:   Linux
>  Load Address: 0x23008000
>  Entry Point:  0x23008000
>  Hash node:'hash@1'
>  Hash algo:sha256
>  Hash value:
> 52f8048436c3f62d9108957cb4f6f7d4e58c8c9931d68ea6f0121f4c661c7ffe
>  Hash len: 32
> Image 1 (fdt@1)
>  Description:  FDT blob
>  Type: Flat Device Tree
>  Compression:  uncompressed
>  Data Start:   0x22165ea4
>  Data Size:21681 Bytes = 21.2 KiB
>  Architecture: ARM
>  Hash node:'hash@1'
>  Hash algo:sha256
>  Hash value:
> c7f32d039871d858dda8d397c3b6a685bc914c78cf70f03d1860f61ecfe9c689
>  Hash len: 32
> Default Configuration: 'config@1'
> Configuration 0 (config@1)
>  Description:  Plain Linux
>  Kernel:   linux_kernel@1
>  FDT:  fdt@1
> ## Checking hash(es) for FIT Image at 2200 ...
>Hash(es) for Image 0 (linux_kernel@1): sha256+
>Hash(es) for Image 1 (fdt@1): sha256+
>
>
> Any input?  This seems like offsets and not knowing where various components
> need to be looking.
>
>
>
>
>
>
> On 27 February 2017 at 16:53, Rick Altherr <ralth...@google.com> wrote:
>>
>> You set the load address for the linux image to the same location as the
>> FIT.  U-Boot verified the hashes on the FIT and then tried to copy the
>> kernel over top the FIT.  I assume you put the FIT in flash.  Pick a
>> location in RAM for the kernel's load addres

Re: [U-Boot] Complete verified uboot example

[Rick Altherr]

You set the load address for the linux image to the same location as the
FIT.  U-Boot verified the hashes on the FIT and then tried to copy the
kernel over top the FIT.  I assume you put the FIT in flash.  Pick a
location in RAM for the kernel's load address.

On Mon, Feb 27, 2017 at 1:49 PM, Ron Brash <ron.br...@gmail.com> wrote:

> Looks like far more progress:
>
> #> setenv my_bootcount 0; bootm 0xD0084000
> Initial value for argc=3
> Final value for argc=3
> ## Current stack ends at 0x23f11db8 *  kernel: cmdline image address =
> 0xd0084000
>Reading image header from dataflash address d0084000 to RAM address
> 2200
>FIT/FDT format image found at 0x2200, size 0x0016c0b1
>Reading image remaining data from dataflash address d0084040 to RAM
> address 2240
> ## Loading kernel from FIT Image at 2200 ...
> No configuration specified, trying default...
> Found default configuration: 'config@1'
>Using 'config@1' configuration
>Trying 'linux_kernel@1' kernel subimage
>  Description:  Linux zImage
>  Type: Kernel Image
>  Compression:  uncompressed
>  Data Start:   0x22dc
>  Data Size:1465544 Bytes = 1.4 MiB
>  Architecture: ARM
>  OS:   Linux
>  Load Address: 0x2200
>  Entry Point:  0x22008000
>  Hash node:'hash@1'
>  Hash algo:sha256
>  Hash value:   5dcf9a4328bca6fe5c3405e03b9a58
> 402dce36f3a4f0c757e52091b050d2bcb2
>  Hash len: 32
>Verifying Hash Integrity ... sha256+ OK
>kernel data at 0x22dc, len = 0x00165cc8 (1465544)
> *  ramdisk: using config 'config@1' from image at 0x2200
> *  ramdisk: no 'ramdisk' in config
> *  fdt: using config 'config@1' from image at 0x2200
> ## Checking for 'FDT'/'FDT Image' at 2200
> ## Loading fdt from FIT Image at 2200 ...
>Using 'config@1' configuration
>Trying 'fdt@1' fdt subimage
>  Description:  FDT blob
>  Type: Flat Device Tree
>  Compression:  uncompressed
>  Data Start:   0x22165ea4
>  Data Size:21681 Bytes = 21.2 KiB
>  Architecture: ARM
>  Hash node:'hash@1'
>  Hash algo:sha256
>  Hash value:   c7f32d039871d858dda8d397c3b6a6
> 85bc914c78cf70f03d1860f61ecfe9c689
>  Hash len: 32
>Verifying Hash Integrity ... sha256+ OK
>Loading fdt from 0x22165ea4 to 0x2800
>Booting using the fdt blob at 0x2800
>of_flat_tree at 0x2800 size 0x54b1
> Initial value for argc=3
> Final value for argc=3
>Loading Kernel Image ... OK
> CACHE: Misaligned operation at range [2200, 22165cc8]
>kernel loaded at 0x2200, end = 0x22165cc8
> images.os.start = 0x2200, images.os.end = 0x2216c0f1
> images.os.load = 0x2200, load_end = 0x22165cc8
> ERROR: new format image overwritten - must RESET the board to recover
> resetting ...
>
> This appears to be an addressing issue.  Anyone care to comment?
>
> I'll put up how I got to this point after, but I am curious on how all of
> the addresses are leveraged, is there an order they follow and more?
>
>
>
> On 27 February 2017 at 15:58, Rick Altherr <ralth...@google.com> wrote:
>
>> The projects I'm working on are based on Yocto so I've been using the
>> u-boot signing support that is built in there.  I believe the magic you are
>> looking for is in http://git.yoctoproject.org
>> /cgit/cgit.cgi/poky/tree/meta/classes/uboot-sign.bbclass.  Specifically,
>> when you run 'mkimage -F -k  -K  -r ', the
>> public keys will be inserted into the control dtb.  You can then rebuild
>> u-boot with 'make EXT_DTB=' which will use the dtb that
>> includes the keys.
>>
>> On Mon, Feb 27, 2017 at 7:34 AM, Ron Brash <ron.br...@gmail.com> wrote:
>>
>>> Okay - it seems, after working my way through a bunch of the
>>> documentation and examples in /doc/uImage.FIT - I noticed a discrepancy
>>>
>>> /dts-v1/;
>>> /{
>>> description = "Configuration to load a Basic Kernel";
>>> #address-cells = <1>;
>>> images {
>>> linux_kernel@1 {
>>> description = "Linux zImage";
>>> data = /incbin/("zImage");
>>> type = "kernel";
>>> arch = "arm";
>>> os = "linux";
>>> compression = "none";
>>> load =  <0x2000>;
>>> entry = <0x20008000>;
>>> kernel-version = <1>;
>>> hash@1 {
>>> algo = "sha256";
>>> };
>>> };
>>> fdt@1 {
>>> description = "FDT blob";
>>> data = /incbin/(

Re: [U-Boot] Complete verified uboot example

[Rick Altherr]

The projects I'm working on are based on Yocto so I've been using the
u-boot signing support that is built in there.  I believe the magic you are
looking for is in
http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/classes/uboot-sign.bbclass.
Specifically, when you run 'mkimage -F -k  -K  -r
', the public keys will be inserted into the control dtb.  You can
then rebuild u-boot with 'make EXT_DTB=' which will use the
dtb that includes the keys.

On Mon, Feb 27, 2017 at 7:34 AM, Ron Brash <ron.br...@gmail.com> wrote:

> Okay - it seems, after working my way through a bunch of the documentation
> and examples in /doc/uImage.FIT - I noticed a discrepancy
>
> /dts-v1/;
> /{
> description = "Configuration to load a Basic Kernel";
> #address-cells = <1>;
> images {
> linux_kernel@1 {
> description = "Linux zImage";
> data = /incbin/("zImage");
> type = "kernel";
> arch = "arm";
> os = "linux";
> compression = "none";
> load =  <0x2000>;
> entry = <0x20008000>;
> kernel-version = <1>;
> hash@1 {
> algo = "sha256";
> };
> };
> fdt@1 {
> description = "FDT blob";
> data = /incbin/("myboard.dtn");
> type = "flat_dt";
> arch = "arm";
> compression = "none";
> fdt-version = <1>;
> hash@1{
> algo = "sha256";
> };
> };
> };
> configurations {
> default = "config@1";
> config@1{
> description = "Plain Linux";
> kernel = "linux_kernel@1";
> fdt = "fdt@1";
> signature@1{
> algo = "sha256,rsa2048";
> key-name-hint = "dev_key";
> sign-images = "fdt", "kernel";
> };
> };
> };
> };
>
> Does NOT equal (for brevity - I just used the node)
>
> fdt@1 {
> description = "FDT blob";
> data = /incbin/("myboard.dtn");
> type = "flat_dt";
> arch = "arm";
> compression = "none";
> fdt-version = <1>;
> hash@1{
> algo = "sha256";
> };
> signature@1{
> algo = "sha256,rsa2048";
> key-name-hint = "dev_key";
> };
> };
>
> Apparently, this causes the mkimage tooling in my particular instance to
> explain invalid blob messages.  The large example above indeed does work
> once this nuance was noticed.
>
> Next,  once the final CTRL FDT is created, how does one get it back into
> the actual u-boot binary.  Does/can mkimage insert it into the binary image
> at a particular offset?  What is the command to do so?
>
>
>
>
>
> On 23 February 2017 at 12:27, Rick Altherr <ralth...@google.com> wrote:
>
>>
>>
>> On Thu, Feb 23, 2017 at 7:48 AM, Ron Brash <ron.br...@gmail.com> wrote:
>>
>>> Hello all (and thanks Mr. Altherr for this insight),
>>>
>>> Excellent feedback and I agree that all of this needs to find a home
>>> either on the global docs on the website and/or the text-only
>>> documentation.  Regardless, this leads me to a few questions.
>>>
>>> NOTE: the use of a uboot control DTS, control DTB and control FTD even
>>> in Mr. Altherr's email is confusion provoking.  One term to rule them all
>>> is needed ;)
>>>
>>
>> Agreed.  Technically a flattened device tree (FDT) can be described in an
>> ASCII form (dts) or binary form (dtb).
>>
>>
>>>
>>> 1.)  What if a board doesn't have OR has ever been configured to use
>>> u-boot DTS (could we call this a UDTS or something friendly to
>>> differentiate that fact?); this was a point of misunderstanding until I
>>> started scampering around into arch/arm/dts/?
>>>
>>> * For example, my board is a derivative of an Atmel at91sam9g20.  It had
>>> a very generic implementation of a DTS that covered reference boards in the
>>> Linux kernel, but required a fair bit of modification to make it work.  As
>>> the at91sam(legacy platform) isn't in u-boot's source tree for a DTS - what
>>> would someone like me need to do - do we have a barebones tutorial (again I
>>> don't mind publishing such with proofing)?  Is it even required if we have
>>> a platform/board already working in the traditional u-boot way?
>>>
>>> I believe (but have no verified) that if your board is supported by
>> U-Boot without a control FDT today, you can just create one that contains
>> only the public keys.  I've gathered from the mailing list that using a
>> control FDT and the driver model is how all new boards should be
>> implemented.
>>

Re: [U-Boot] U-boot FIT Signature

[Rick Altherr]

How would you verify that the public key hasn't been tampered with?

On Fri, Feb 17, 2017 at 12:37 AM, Maria Sepulveda 
wrote:

> Good morning,
>
> I am working with FIT image in U-Boot 2013.07. I have configured the image
> verification with signed image and kernel boots fine so, I would like to
> know if I can store my public key in an external device (like crypto-memory
> or an i2c device) because I am storing the key in DBT with the
> CONFIG_OF_CONTROL configuration.
>  The aim of this is that U-Boot should check the i2c address of my
> external device, read the public key and verify the signed image later.
> I work with am335x board and Kernel 3.14.
>
> Thanks in advanced,
>
> --
> María Sepúlveda Paños Engineering Department COJALI, S. L.
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] where is (eg) "BOOT_TARGET_DEVICES_references_MMC_without_CONFIG_CMD_MMC" defined?

[Rick Altherr]

include/config_distro_bootcmd.h:65 defines BOOTENV_DEV_MMC when
CONFIG_CMD_MMC is defined.  Otherwise, line 69 does.  In the former case,
BOOTENV_DEV_MMC is defined to BOOTENV_DEV_BLKDEV which is a macro that
takes 3 arguments.  In the latter case, BOOTENV_DEV_MMC is defined
to BOOT_TARGET_DEVICES_references_MMC_without_CONFIG_CMD_MMC which is not
defined at all.  Since there isn't a macro of that name and it takes
arguments, the compiler assumes it must be a function.  Depending on
compiler, flags, etc, that will either compile (assuming int return type,
etc) or not.  If it does compile, it will fail to link as that symbol is
never defined.

On Mon, Feb 6, 2017 at 4:06 AM, Robert P. J. Day 
wrote:

>
>   i'm sure i'm missing something obvious, but i'm perusing
> "include/config_distro_bootcmd.h" for the first time, and i can
> understand the *principle* behind:
>
> /*
>  * A note on error handling: It is possible for BOOT_TARGET_DEVICES to
>  * reference a device that is not enabled in the U-Boot configuration, e.g.
>  * it may include MMC in the list without CONFIG_CMD_MMC being enabled.
> Given
>  * that BOOT_TARGET_DEVICES is a macro that's expanded by the C
> pre-processor
>  * at compile time, it's not  possible to detect and report such problems
> via
>  * a simple #ifdef/#error combination. Still, the code needs to report
> errors.
>  * The best way I've found to do this is to make BOOT_TARGET_DEVICES
> expand to
>  * reference a non-existent symbol, and have the name of that symbol encode
>  * the error message. Consequently, this file contains references to e.g.
>  * BOOT_TARGET_DEVICES_references_MMC_without_CONFIG_CMD_MMC. Given the
>  * prevalence of capitals here, this looks like a pre-processor macro and
>  * hence seems like it should be all capitals, but it's really an error
>  * message that includes some other pre-processor symbols in the text.
>  */
>
> but, still, how is that name resolved to the corresponding error
> message? what am i missing here?
>
> rday
>
> --
>
> 
> Robert P. J. Day Ottawa, Ontario, CANADA
> http://crashcourse.ca
>
> Twitter:   http://twitter.com/rpjday
> LinkedIn:   http://ca.linkedin.com/in/rpjday
> 
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] bootz/booti: relocate ramdisk if CONFIG_SYS_BOOT_RAMDISK_HIGH set

[Rick Altherr]

Whoops.  Thank you for catching that.

Reviewed-by: Rick Altherr <ralth...@google.com>

On Mon, Jan 23, 2017 at 7:51 AM, Cédric Schieli <cschi...@gmail.com> wrote:

> In commit c2e7e72, the ramdisk relocation code was moved from
> image_setup_linux to do_bootm, leaving the bootz and booti cases broken.
>
> This patch fixes both by adding the BOOTM_STATE_RAMDISK state in their
> call to do_bootm_states if CONFIG_SYS_BOOT_RAMDISK_HIGH is set.
>
> Signed-off-by: Cédric Schieli <cschi...@gmail.com>
> ---
>
>  cmd/booti.c | 3 +++
>  cmd/bootz.c | 3 +++
>  2 files changed, 6 insertions(+)
>
> diff --git a/cmd/booti.c b/cmd/booti.c
> index 6c1c998..2d879f3 100644
> --- a/cmd/booti.c
> +++ b/cmd/booti.c
> @@ -132,6 +132,9 @@ int do_booti(cmd_tbl_t *cmdtp, int flag, int argc,
> char * const argv[])
>
> images.os.os = IH_OS_LINUX;
> ret = do_bootm_states(cmdtp, flag, argc, argv,
> +#ifdef CONFIG_SYS_BOOT_RAMDISK_HIGH
> + BOOTM_STATE_RAMDISK |
> +#endif
>   BOOTM_STATE_OS_PREP | BOOTM_STATE_OS_FAKE_GO
> |
>   BOOTM_STATE_OS_GO,
>   , 1);
> diff --git a/cmd/bootz.c b/cmd/bootz.c
> index 9648fe9..ceff01b 100644
> --- a/cmd/bootz.c
> +++ b/cmd/bootz.c
> @@ -76,6 +76,9 @@ int do_bootz(cmd_tbl_t *cmdtp, int flag, int argc, char
> * const argv[])
>
> images.os.os = IH_OS_LINUX;
> ret = do_bootm_states(cmdtp, flag, argc, argv,
> +#ifdef CONFIG_SYS_BOOT_RAMDISK_HIGH
> + BOOTM_STATE_RAMDISK |
> +#endif
>   BOOTM_STATE_OS_PREP | BOOTM_STATE_OS_FAKE_GO
> |
>   BOOTM_STATE_OS_GO,
>   , 1);
> --
> 2.10.2
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot