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 > 22000000 > FIT/FDT format image found at 0x22000000, size 0x0016c0b1 > Reading image remaining data from dataflash address d0084040 to RAM > address 22000040 > ## Loading kernel from FIT Image at 22000000 ... > 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: 0x220000dc > Data Size: 1465544 Bytes = 1.4 MiB > Architecture: ARM > OS: Linux > Load Address: 0x22000000 > 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 0x220000dc, len = 0x00165cc8 (1465544) > * ramdisk: using config 'config@1' from image at 0x22000000 > * ramdisk: no 'ramdisk' in config > * fdt: using config 'config@1' from image at 0x22000000 > ## Checking for 'FDT'/'FDT Image' at 22000000 > ## Loading fdt from FIT Image at 22000000 ... > 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 0x28000000 > Booting using the fdt blob at 0x28000000 > of_flat_tree at 0x28000000 size 0x000054b1 > Initial value for argc=3 > Final value for argc=3 > Loading Kernel Image ... OK > CACHE: Misaligned operation at range [22000000, 22165cc8] > kernel loaded at 0x22000000, end = 0x22165cc8 > images.os.start = 0x22000000, images.os.end = 0x2216c0f1 > images.os.load = 0x22000000, 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 <key-name> -K <control-dtb> -r <fit>', the >> public keys will be inserted into the control dtb. You can then rebuild >> u-boot with 'make EXT_DTB=<control-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 = <0x20000000>; >>> 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. >>>> >>>> >>>>> 2.) Just to summarise - everything winds up in two binaries: u-boot >>>>> and the FIT image. So the partition scheme would more or less would look >>>>> like: >>>>> >>>>> /----------------- >>>>> * Bootstrap/ROM (optional) >>>>> /---------------- >>>>> * U-boot >>>>> * Control DTB >>>>> * Has keys >>>>> >>>> >>>> Only the public keys. The private keys are never stored on the target >>>> device. >>>> >>>> >>>>> * Driver loadout/init >>>>> >>>> The control FDT only describes the hardware (see >>>> https://www.devicetree.org/ and http://git.kernel.org/cgit/lin >>>> ux/kernel/git/torvalds/linux.git/tree/Documentation/devicetr >>>> ee/usage-model.txt). U-Boot's driver model matches device drivers >>>> against nodes in the FDT and starts them. >>>> >>>> >>>>> /---------------- >>>>> * U-boot env >>>>> *---------------- >>>>> * FIT image >>>>> >>>> The FIT shouldn't be in the U-Boot env section. That's used by U-Boot >>>> to store its persistent environment. The FIT is a replacement for the >>>> kernel image. Keep a separate place allocated in the flash for kernel but >>>> store the FIT there. >>>> >>>> >>>>> * ITS >>>>> >>>> I never really thought of it this way, but yes, that's true. The ITS >>>> is itself written in device tree syntax and gets compiled to binary form. >>>> dtb tends to get used only to describe device trees in binary form that >>>> describe hardware. Maybe we need to introduce ITB to clarify this is the >>>> device tree in binary form describing the image. >>>> >>>> >>>>> * Kernel >>>>> * DTS >>>>> >>>> >>>> Prefer the terms FDT or DTB. Only the compiled form is stored in the >>>> FIT. >>>> >>>> >>>>> * .... >>>>> /--------------- >>>>> * Rootfs etc... >>>>> * ... >>>>> /--------------- >>>>> >>>>> >>>>> 3.) What people used to use to load X address into Z location in >>>>> memory is now removed by the usage of a DTB in u-boot correct? I assume >>>>> that the u-boot DTB now does this and bootarg/bootcmd is partially done >>>>> away with - as its arguments are augmented by said file. >>>>> >>>> >>>> Not quite. bootarg/bootcmd is still used. What is different is that >>>> booting linux with a FDT with legacy images required multiple arguments to >>>> bootm. In that case, bootarg would be 'bootm <zimage_addr> - <fdt_addr>'. >>>> With a FIT, you only provide the address of the FIT itself to bootm so >>>> bootarg is set to 'bootm <fit_addr>'. >>>> >>>> >>>>> >>>>> Anybody have the spare cycles to organise a >>>>> web-tutorial/presentation/recording with me on a play-by-play to make >>>>> all of this make sense? I'm aiming to be in Prague for the 2017 >>>>> conference >>>>> in October, might be a good place to showcase this fine-tuning. >>>>> >>>>> >>>> I'm not clear on what you are asking. I probably have time to review >>>> docs and presentations and maybe a few phone or video conference meetings. >>>> >>>> >>>>> Ron >>>>> >>>>> On 22 February 2017 at 13:51, Rick Altherr <ralth...@google.com> >>>>> wrote: >>>>> >>>>>> >>>>>> On Tue, Feb 21, 2017 at 10:08 AM, Ron Brash <ron.br...@gmail.com> >>>>>> wrote: >>>>>> >>>>>>> Hello all, >>>>>>> >>>>>>> I am adding verified kernel support on a board we are using and I am >>>>>>> struggling to fully understand all of the concepts and steps >>>>>>> required to >>>>>>> pull everything together (on ARM, using ZImages and booting with a >>>>>>> working >>>>>>> DTB on 4.4.3x). I also looked at the test script inside of >>>>>>> examples, but >>>>>>> it left me with more questions than understanding. >>>>>>> >>>>>>> Please correct me where appropriate in my understanding, but if I am >>>>>>> confused, likely others are too and I hope this helps everyone >>>>>>> involved >>>>>>> overall. >>>>>>> >>>>>> >>>>>> You've asked some really good questions. Hopefully this discussion >>>>>> will end up with patches to clarify the docs. >>>>>> >>>>>> >>>>>>> >>>>>>> Steps: >>>>>>> --------------------------------------------------------------- >>>>>>> >>>>>>> First, u-boot needs to have the appropriate features enabled and to >>>>>>> be >>>>>>> built using them. At a minimum, I suspect: >>>>>>> >>>>>>> CONFIG_RSA=y >>>>>>> CONFIG_FIT=y >>>>>>> CONFIG_FIT_SIGNATURE=y >>>>>>> CONFIG_OF_CONTROL=y >>>>>>> >>>>>>> >>>>>> Yup. That looks right. >>>>>> >>>>>> >>>>>>> Next, we need to derive the appropriate cryptographic >>>>>>> primitives/keys. >>>>>>> >>>>>>> #Generate a private signing key (RSA2048): >>>>>>> openssl genrsa -F4 -out \ >>>>>>> "${key_dir}"/"${key_name}".key 2048 >>>>>>> >>>>>>> # Generate a public key: >>>>>>> openssl req -batch -new -x509 \ >>>>>>> -key "${key_dir}"/"${key_name}".key \ >>>>>>> -out "${key_dir}"/"${key_name}".crt >>>>>>> >>>>>>> >>>>>> So far so good. In general, I suggest having multiple signing keys. >>>>>> You can put all the public keys in your u-boot so an image signed with >>>>>> any >>>>>> of those keys will be accepted. If you happen to have a signing key >>>>>> compromised, you can switch to one of the other ones. With that other >>>>>> key, >>>>>> you can sign an update the removes the compromised public key from future >>>>>> images. >>>>>> >>>>>> >>>>>>> Then we derive the ITS or image source file - a file that >>>>>>> hints/describes >>>>>>> the elements that will be verified and/or inside of the FIT image? >>>>>>> Lets >>>>>>> call this $FIT_ITS >>>>>>> >>>>>>> FIT is a container format. Generally, you'll create a FIT that >>>>>> contains the zImage, dtb, initramfs, etc. With FIT support enabled in >>>>>> u-boot, you only need to provide the single FIT image address to 'bootm'. >>>>>> u-boot will use the config section to find the individual elements, load >>>>>> them into RAM as needed, and boot. >>>>>> >>>>>> >>>>>>> / dts - v1 /; >>>>>>> / { >>>>>>> description = "Configuration to load a Xen Kernel"; >>>>>>> #address-cells = <1>; >>>>>>> images { >>>>>>> linux_kernel @ 1 { >>>>>>> description = "Linux zImage"; >>>>>>> data = /incbin / ("pathToImage/zImage"); >>>>>>> type = "kernel"; >>>>>>> arch = "arm"; >>>>>>> os = "linux"; >>>>>>> compression = "none"; >>>>>>> load = <0xaf600000 >; >>>>>>> entry = <0xaf600000 >; >>>>>>> hash @ 1 { >>>>>>> algo = "sha1"; >>>>>>> }; >>>>>>> }; >>>>>>> fdt @ 1 { >>>>>>> description = "FDT blob"; >>>>>>> data = /incbin / ("PathToDTBUsedByBootingKernel/ex.dtb"); >>>>>>> type = "flat_dt"; >>>>>>> arch = "arm"; >>>>>>> compression = "none"; >>>>>>> load = <0xaec00000 >; >>>>>>> >>>>>> >>>>>> You generally don't need a 'load' property for the FDT or an >>>>>> initramfs. Without one, U-Boot will allocate RAM dynamically, if needed, >>>>>> and pass the relocated address to the kernel. >>>>>> >>>>>> hash @ 1 { >>>>>>> algo = "sha1"; >>>>>>> }; >>>>>>> }; >>>>>>> }; >>>>>>> configurations { >>>>>>> default = "config@1"; >>>>>>> config @ 1 { >>>>>>> description = "Plain Linux"; >>>>>>> kernel = "linux_kernel@1"; >>>>>>> fdt = "fdt@1"; >>>>>>> loadables = "linux_kernel@1"; >>>>>>> >>>>>> >>>>>> 'loadables' is for other types of firmware. You only need the >>>>>> 'kernel' property for loading and booting the kernel. >>>>>> >>>>>> >>>>>>> }; >>>>>>> }; >>>>>>> }; >>>>>>> >>>>>>> Question: Does a signature section go into this as well? underneath >>>>>>> the >>>>>>> hash node for each value? >>>>>> >>>>>> >>>>>>> signature@1 { >>>>>>> algo = "sha1,rsa2048"; >>>>>>> value = <...kernel signature 1...> >>>>>>> }; >>>>>>> >>>>>> >>>>>> You add a signature section to each image you want signed within the >>>>>> FIT. In your case, add one for both the kernel and FDT images. >>>>>> Signatures >>>>>> go _next_ to the hash section, not in it. Omit the 'value' property as >>>>>> it >>>>>> will be generated for you later. >>>>>> >>>>>> >>>>>>> >>>>>>> Then using the device-tree-compiler (dtc), I create a DTB for >>>>>>> u-boot. This >>>>>>> is the control FDT and this defines what keys are used etc.. >>>>>>> >>>>>> >>>>>> The control FDT is used for U-Boot's driver model _as well as_ >>>>>> providing public keys for verifying images. Your board may not currently >>>>>> use a control FDT in which case you create one from scratch. >>>>>> >>>>>> >>>>>>> >>>>>>> #Assemble control FDT for U-Boot with space for public key: >>>>>>> $DTC -p 0x1000 u-boot.dts -O dtb -o u-boot.dtb >>>>>>> >>>>>>> Question: What is required inside of the u-boot.dts for u-boot? Is >>>>>>> it >>>>>>> simply the same .dts used by the booting kernel, but with a section >>>>>>> proclaiming the keys? >>>>>>> >>>>>> >>>>>> This depends on the board you are using. For example, an AST2500 >>>>>> requires a DTB for U-Boot to load the right drivers. The DTB used by >>>>>> U-Boot is slightly different from that used by Linux as the Linux DTB >>>>>> often >>>>>> includes addition configuration information. When using verified boot, >>>>>> the >>>>>> U-Boot DTB includes the public keys whereas the FDT/DTB stored in the FIT >>>>>> does not as Linux doesn't need them. >>>>>> >>>>>> >>>>>>> >>>>>>> Question: Where will the compiled u-boot.dtb eventually go? Is >>>>>>> this put >>>>>>> into a FIT image, or flashed onto the board alongside the u-boot >>>>>>> bootloader >>>>>>> itself? >>>>>>> >>>>>> >>>>>> The U-Boot control FDT is compiled into the U-Boot binary. The FDT >>>>>> in the FIT is the FDT that is provided to Linux. >>>>>> >>>>>> >>>>>>> >>>>>>> Next, given that the above steps are completed, I need to create a >>>>>>> FIT >>>>>>> image with space for the signature. >>>>>>> >>>>>>> # Generate fitImage with space for signature: >>>>>>> $MKIMG -D "-I dts -O dtb -p 2000" \ >>>>>>> -f f$FIT_ITS $FIT_IMG >>>>>>> >>>>>>> Question: Is the FIT_IMAGE the actual zimage or is it an output >>>>>>> image that >>>>>>> contains all of the values contained within the ITS? >>>>>>> >>>>>> >>>>>> The latter. It will have a compiled version of the ITS as well as >>>>>> the actual images specified in the ITS (kernel, fdt). >>>>>> >>>>>> >>>>>>> >>>>>>> Next this FIT_IMAGE (assuming that this is the final FIT image that >>>>>>> contains the FDT and zImage) needs to be signed and the public key >>>>>>> added to >>>>>>> it; given that that the key information is in the uboot. >>>>>>> >>>>>> >>>>>> You sign the FIT_IMAGE and put the public keys in the control DTB. >>>>>> >>>>>> >>>>>>> >>>>>>> # Sign fitImage and add public key into u-boot.dtb: >>>>>>> $MKIMG -D "-I dts -O dtb -p 2000" -F \ >>>>>>> -k "${key dir}" -K u-boot.dtb -r $FIT_IMG >>>>>>> >>>>>> >>>>>> This is putting the public keys used by the FIT image into the >>>>>> control DTB >>>>>> >>>>>> >>>>>>> >>>>>>> Then, we sign the subsequent fitImage again - correct? >>>>>>> >>>>>>> # Signing subsequent fitImage: >>>>>>> $MKIMG -D "-I dts -O dtb -p 2000" \ >>>>>>> -k "${key dir}" -f $FIT_ITS -r $FIT_IMG >>>>>>> >>>>>> >>>>>> This is generating signatures for the images in the FIT and storing >>>>>> those signatures in the FIT. >>>>>> >>>>>> >>>>>>> >>>>>>> Now that all of the above is done - we need to: >>>>>>> 1. Write our uboot to the flash >>>>>>> 2. Write our FIT_IMAGE to flash >>>>>>> >>>>>>> Question: Do we write anything else to persistent storage? The ITS? >>>>>>> etc.. >>>>>>> >>>>>> >>>>>> No. Everything is contained in the U-Boot binary (control FDT >>>>>> including public keys) and the FIT (images, signatures) >>>>>> >>>>>>> >>>>>>> Question: Do we just boot using anything else or just bootm >>>>>>> 0xLocationOfTheFitImageInRAM >>>>>>> >>>>>> >>>>>> The latter. bootm will check the config section in the FIT and use >>>>>> the kernel, fdt, etc specified there. >>>>>> >>>>>> >>>>>>> >>>>>>> Greatly appreciate any assistance to all of these questions and I'm >>>>>>> sure >>>>>>> this threat will be of interest to anyone else too. >>>>>>> >>>>>>> Thanks! >>>>>> >>>>>> _______________________________________________ >>>>>>> U-Boot mailing list >>>>>>> U-Boot@lists.denx.de >>>>>>> http://lists.denx.de/mailman/listinfo/u-boot >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>> >>> >>> -- >>> >>> >>> Ron Brash >>> CTO & Co-founder of Atlants Embedded Inc. >>> www.atlantsembedded.com >>> ------------------------------------------------------------------ >>> >>> Cell +1 438 880 6441 <(438)%20880-6441> >>> Email ron.br...@gmail.com >>> Blog www.pacificsimplicity.ca >>> LinkedIn ca.linkedin.com/in/ronbrash/ >>> >>> >>> >>> This communication is intended for the use of the recipient to which it >>> is >>> addressed, and may contain confidential, personal, and or privileged >>> information. Please contact the sender immediately if you are not the >>> intended recipient of this communication, and do not copy, distribute, or >>> take action relying on it. Any communication received in error, or >>> subsequent reply, should be deleted or destroyed. >>> >> >> > > > -- > > > Ron Brash > CTO & Co-founder of Atlants Embedded Inc. > www.atlantsembedded.com > ------------------------------------------------------------------ > > Cell +1 438 880 6441 <(438)%20880-6441> > Email ron.br...@gmail.com > Blog www.pacificsimplicity.ca > LinkedIn ca.linkedin.com/in/ronbrash/ > > > > This communication is intended for the use of the recipient to which it is > addressed, and may contain confidential, personal, and or privileged > information. Please contact the sender immediately if you are not the > intended recipient of this communication, and do not copy, distribute, or > take action relying on it. Any communication received in error, or > subsequent reply, should be deleted or destroyed. > _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/listinfo/u-boot
