two questions on verified boot

* two questions on verified boot
@ 2021-11-21 14:55 Rasmus Villemoes
  2021-11-21 19:32 ` Dhananjay Phadke
  2022-01-27 15:06 ` Simon Glass
  0 siblings, 2 replies; 5+ messages in thread
From: Rasmus Villemoes @ 2021-11-21 14:55 UTC (permalink / raw)
  To: u-boot; +Cc: Simon Glass

(1) When one wants to get rid of CONFIG_LEGACY_IMAGE_FORMAT, one also
has to wrap any boot script in a FIT rather than a uImage. While it's
not directly documented anywhere how to do that, it seems that a minimal
.its for achieving it is

/dts-v1/;

/ {
	description = "U-Boot script(s)";

	images {
		default = "boot";
		boot {
			description = "Bootscript";
			data = /incbin/("boot.txt");
			type = "script";
			compression = "none";
			hash-1 {
				algo = "sha256";
			};
		};
	};
};

[The UX when one doesn't guess that the description string is mandatory
is rather sad, but that's a separate story.]

Now, I can get that signed if I include a signature-foo node inside the
"boot" node, and also add a dummy empty /configurations node (otherwise
mkimage refuses to process it). But that will only work if I have added
a "required = image" property with the public key; if I want to use the
safer/saner "required = conf", how do I make sure any boot script is
properly signed?

The code in source.c only cares about the images node and calls
fit_image_verify(), and there's no concept of "configuration" and
combining multiple images when talking about a simple boot script.

(2) Assuming for the moment that I would be happy with just using
required=image, am I right in that not only does that mean that the
combination of kernel/fdt/initramfs is not verified, merely the
individual parts, but more importantly (a mix'n'match attack isn't
really very likely), _only_ the data property in each node is part of
what gets signed, not the other important properties such as load= and
entry=? IOW, suppose I have a FIT image with

  images {
     kernel {
        data = blabla;
        load = 0x1000000;
        entry = 0x10000000;
        signature {
           ... // correct signature of blabla
        };
     };
   };

and I know that the boot process uses $loadaddr = 0x40000000. What is to
stop me from modifying that FIT image to read

  images {
     kernel {
        data = blabla;
        load = 0x1000000;
        entry = 0x400abcde;
        signature {
           ... // correct signature of blabla
        };
     };
  };
  some-other-node {
      pwned = /incbin/("pwned");
  };

where 0xabcde is chosen to coincide with where the data part of the
pwned property lies in the modified FIT? (That pwned property can be put
anywhere; I could even just replace the signer-name property inside the
signature node with a value of "mkimage\0<padding><my payload>".)

In fit_config_process_sig(), there's this elaborate dance with
fit_config_get_data()/fdt_find_regions() which, AFAICT, ends up
including all the property values (and the FDT_PROP tags and string
offsets etc.), and then we call info.crypto->sign() with some
appropriate region_count. But in fit_image_process_sig(), we call
info.crypto->sign() with nregions==1, and AFAICT, the data being signed
is just the value of the "data" property, nothing else.

Rasmus

^ permalink raw reply	[flat|nested] 5+ messages in thread