common: fit: Allow U-Boot images to be booted

PATCH New Mario Six 4 participants 8 messages Jul 18, 2016 – Jul 19, 2016

Share & tools

Mario Six

author

2016-07-18 12:05 UTC #0 lore raw

PATCH 1/1 common: fit: Allow U-Boot images to be booted

In certain circumstances it comes in handy to be able to boot into a second U-Boot. But as of now it is not possible to boot a U-Boot binary that is inside a FIT image, which is problematic for projects that e.g. need to guarantee a unbroken chain of trust from SOC all the way into the OS, since the FIT signing mechanism cannot be used.

This patch adds the capability to load such FIT images.

An example its snippet (utilizing signature verification) might look like the following:

images {
	kernel at 1 {
		description = "2nd stage U-Boot image";
		data = /incbin/("u-boot-dtb.img.gz");
		type = "kernel";
		arch = "arm";
		os = "u-boot";
		compression = "gzip";
		load = <0x8FFFC0>;
		entry = <0x900000>;
		signature at 1 {
			algo = "sha256,rsa4096";
			key-name-hint = "key";
		};
	};
};

Signed-off-by Mario Six <[email protected]>

---
 common/image-fit.c | 1 +
 1 file changed, 1 insertion(+)

common/image-fit.c +1 -0

index 6f920da..0c7b400 100644
@@ -1690,6 +1690,7 @@ int fit_image_load(bootm_headers_t *images, ulong addr,
 
 	os_ok = image_type == IH_TYPE_FLATDT || IH_TYPE_FPGA ||
 		fit_image_check_os(fit, noffset, IH_OS_LINUX) ||
+		fit_image_check_os(fit, noffset, IH_OS_U_BOOT) ||
 		fit_image_check_os(fit, noffset, IH_OS_OPENRTOS);
 
 	/*

--
2.9.0

Tom Rini

2016-07-18 15:59 UTC #1 lore raw

PATCH 1/1 common: fit: Allow U-Boot images to be booted

Quoted 28 lines · Mario Six

In certain circumstances it comes in handy to be able to boot into a second U-Boot. But as of now it is not possible to boot a U-Boot binary that is inside a FIT image, which is problematic for projects that e.g. need to guarantee a unbroken chain of trust from SOC all the way into the OS, since the FIT signing mechanism cannot be used.
This patch adds the capability to load such FIT images.
An example its snippet (utilizing signature verification) might look like the following:
images {
	kernel at 1 {
		description = "2nd stage U-Boot image";
		data = /incbin/("u-boot-dtb.img.gz");
		type = "kernel";
		arch = "arm";
		os = "u-boot";
		compression = "gzip";
		load = <0x8FFFC0>;
		entry = <0x900000>;
		signature at 1 {
			algo = "sha256,rsa4096";
			key-name-hint = "key";
		};
	};
};

Quoted 1 line

Signed-off-by Mario Six <[email protected]>

Reviewed-by Tom Rini <[email protected]>

Signature · 8 lines

Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160718/48c688b3/attachment.sig>

Michal Simek

2016-07-19 05:46 UTC #2 lore raw

PATCH 1/1 common: fit: Allow U-Boot images to be booted

In reply to Mario Six

Quoted 8 lines · Mario Six

In certain circumstances it comes in handy to be able to boot into a second U-Boot. But as of now it is not possible to boot a U-Boot binary that is inside a FIT image, which is problematic for projects that e.g. need to guarantee a unbroken chain of trust from SOC all the way into the OS, since the FIT signing mechanism cannot be used.
This patch adds the capability to load such FIT images.

Quoted 8 lines

An example its snippet (utilizing signature verification) might look like the following:
images {
	kernel at 1 {
		description = "2nd stage U-Boot image";
		data = /incbin/("u-boot-dtb.img.gz");
		type = "kernel";

Isn't this type weird for u-boot itself?

The rest is good.

Thanks,
Michal

Mario Six

author

2016-07-19 06:45 UTC #3 lore raw

PATCH 1/1 common: fit: Allow U-Boot images to be booted

Quoted 18 lines · Michal Simek

Quoted 8 lines · Mario Six
In certain circumstances it comes in handy to be able to boot into a second U-Boot. But as of now it is not possible to boot a U-Boot binary that is inside a FIT image, which is problematic for projects that e.g. need to guarantee a unbroken chain of trust from SOC all the way into the OS, since the FIT signing mechanism cannot be used.
This patch adds the capability to load such FIT images.
Quoted 8 lines
An example its snippet (utilizing signature verification) might look like the following:
images {
      kernel at 1 {
              description = "2nd stage U-Boot image";
              data = /incbin/("u-boot-dtb.img.gz");
              type = "kernel";

Quoted 6 lines

Isn't this type weird for u-boot itself?
The rest is good.
Thanks,
Michal

It is, but the problem is that adding a new type, like "ubootimage," or something like that, would not be as easy as with the platform-specific image types (like, e.g. "rkimage"), which only appear in mkimage, because we'd have to account for this new type in common/bootm.c (essentially, add a lot of additional "|| images.os.type == IH_TYPE_UBOOT").

I didn't think that it was worth the hassle, and it would have the additional minor problem that it would effectively be a synonym of "kernel," so you could declare a regular kernel as having type "ubootimage," and U-Boot would happily boot it; to prevent that we'd have to do more checks, like, e.g. check the os value against the type and only boot if the combination makes sense or some such.

It would be nicer to have a dedicated type, but I think it's too much effort for such a fringe use case; should it become popular, though, I'll happily add a new type :-)

Best regards,

Mario

Michal Simek

2016-07-19 06:47 UTC #4 lore raw

PATCH 1/1 common: fit: Allow U-Boot images to be booted

Quoted 39 lines · Mario Six

Quoted 18 lines · Michal Simek
Quoted 8 lines · Mario Six
In certain circumstances it comes in handy to be able to boot into a second U-Boot. But as of now it is not possible to boot a U-Boot binary that is inside a FIT image, which is problematic for projects that e.g. need to guarantee a unbroken chain of trust from SOC all the way into the OS, since the FIT signing mechanism cannot be used.
This patch adds the capability to load such FIT images.
Quoted 8 lines
An example its snippet (utilizing signature verification) might look like the following:
images {
      kernel at 1 {
              description = "2nd stage U-Boot image";
              data = /incbin/("u-boot-dtb.img.gz");
              type = "kernel";
Quoted 6 lines
Isn't this type weird for u-boot itself?
The rest is good.
Thanks,
Michal
It is, but the problem is that adding a new type, like "ubootimage," or something like that, would not be as easy as with the platform-specific image types (like, e.g. "rkimage"), which only appear in mkimage, because we'd have to account for this new type in common/bootm.c (essentially, add a lot of additional "|| images.os.type == IH_TYPE_UBOOT").
I didn't think that it was worth the hassle, and it would have the additional minor problem that it would effectively be a synonym of "kernel," so you could declare a regular kernel as having type "ubootimage," and U-Boot would happily boot it; to prevent that we'd have to do more checks, like, e.g. check the os value against the type and only boot if the combination makes sense or some such.

Quoted 3 lines

It would be nicer to have a dedicated type, but I think it's too much effort for such a fringe use case; should it become popular, though, I'll happily add a new type :-)

Is the type property even required for this case?

Thanks,
Michal

Mario Six

author

2016-07-19 07:04 UTC #5 lore raw

PATCH 1/1 common: fit: Allow U-Boot images to be booted

Quoted 40 lines · Michal Simek

Quoted 39 lines · Mario Six
Quoted 18 lines · Michal Simek
Quoted 8 lines · Mario Six
In certain circumstances it comes in handy to be able to boot into a second U-Boot. But as of now it is not possible to boot a U-Boot binary that is inside a FIT image, which is problematic for projects that e.g. need to guarantee a unbroken chain of trust from SOC all the way into the OS, since the FIT signing mechanism cannot be used.
This patch adds the capability to load such FIT images.
Quoted 8 lines
An example its snippet (utilizing signature verification) might look like the following:
images {
      kernel at 1 {
              description = "2nd stage U-Boot image";
              data = /incbin/("u-boot-dtb.img.gz");
              type = "kernel";
Quoted 6 lines
Isn't this type weird for u-boot itself?
The rest is good.
Thanks,
Michal
It is, but the problem is that adding a new type, like "ubootimage," or something like that, would not be as easy as with the platform-specific image types (like, e.g. "rkimage"), which only appear in mkimage, because we'd have to account for this new type in common/bootm.c (essentially, add a lot of additional "|| images.os.type == IH_TYPE_UBOOT").
I didn't think that it was worth the hassle, and it would have the additional minor problem that it would effectively be a synonym of "kernel," so you could declare a regular kernel as having type "ubootimage," and U-Boot would happily boot it; to prevent that we'd have to do more checks, like, e.g. check the os value against the type and only boot if the combination makes sense or some such.

Quoted 8 lines

Quoted 3 lines
It would be nicer to have a dedicated type, but I think it's too much effort for such a fringe use case; should it become popular, though, I'll happily add a new type :-)
Is the type property even required for this case?
Thanks,
Michal

I just tried to boot one without the type, and apparently it is required:

## Loading kernel from FIT Image at 02000000 ...
Using 'config at 1' configuration
Verifying Hash Integrity ... OK
Trying 'kernel at 1' kernel subimage

     Description:  2nd stage U-Boot image
     Type:         Unknown Image
     Compression:  gzip compressed
     Data Start:   0x020000d4
     Data Size:    206485 Bytes = 201.6 KiB
     Sign algo:    sha256,rsa4096:ccdc
     Sign value:   ...

Verifying Hash Integrity ... sha256,rsa4096:ccdc+ OK
No U-Boot ARM Kernel Image Image
ERROR: can't get kernel image!

That makes sense, since common/bootm.c checks the image type in several places.

Best regards,

Mario

Wolfgang Denk

2016-07-19 07:14 UTC #6 lore raw

PATCH 1/1 common: fit: Allow U-Boot images to be booted

In reply to Mario Six

Dear Mario,

Quoted 6 lines · In message <CAN1kZorTfQcVoOz5O5J7-R-T5yTDbrCqDBHgC4gHaMX1sUh3YQ@mail.gmail.com>…

It is, but the problem is that adding a new type, like "ubootimage," or something like that, would not be as easy as with the platform-specific image types (like, e.g. "rkimage"), which only appear in mkimage, because we'd have to account for this new type in common/bootm.c (essentially, add a lot of additional "|| images.os.type == IH_TYPE_UBOOT").

There is no need for a new type. IH_TYPE_FIRMWARE should be used for this; see also comments around [1]

[1] http://git.denx.de/?p=u-boot.git;a=blob;f=include/image.h#l228

Best regards,

Wolfgang Denk

Signature · 7 lines

DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"Obviously, a major malfunction has occurred."
              -- Steve Nesbitt, voice of Mission Control, January 28,
                 1986, as the shuttle Challenger exploded within view
                 of the grandstands.

Mario Six

author

2016-07-19 07:41 UTC #7 lore raw

PATCH 1/1 common: fit: Allow U-Boot images to be booted

Hi Wolfgang,

Quoted 10 lines · Wolfgang Denk

Dear Mario,
Quoted 6 lines · In message <CAN1kZorTfQcVoOz5O5J7-R-T5yTDbrCqDBHgC4gHaMX1sUh3YQ@mail.gmail.com>…
It is, but the problem is that adding a new type, like "ubootimage," or something like that, would not be as easy as with the platform-specific image types (like, e.g. "rkimage"), which only appear in mkimage, because we'd have to account for this new type in common/bootm.c (essentially, add a lot of additional "|| images.os.type == IH_TYPE_UBOOT").

Quoted 9 lines

There is no need for a new type. IH_TYPE_FIRMWARE should be used for this; see also comments around [1]
[1] http://git.denx.de/?p=u-boot.git;a=blob;f=include/image.h#l228
Best regards,
Wolfgang Denk

Ah, OK, I thought that IH_TYPE_FIRMWARE should exclusively be used for firmware updates, like the comment said, not for actually *running* the firmware. In that case the work is more manageable (there's still some changes needed, because common/image-fit.c refuses to boot images with firmware type, too).

I'll look into preparing a v2.

Thanks for the help!

Best regards,

Mario