Feature: images in image support

[ozersa]

This PR introduce an proposal method that can be used to handle multi image in a single image pack to decrease number of signature check during bootup. By this change multiple images can be loaded/updated on device with one signature check. Depend on the product this feature might requires to decrease boot up time.

This PR includes:

• combine_images.py which is used to combine images and generate mcuboot image structure by using imgtool.
• combine_images.yaml is provide each images parameters. It is a reference file to demonstrate how can it be used.

The feature only support for if (BOOT_IMAGE_NUMBER == 1) and MCUBOOT_RAM_LOAD defined case. And assume on multicore heterogeneous system the host core which execute MCUBoot FW able to access sub core ITCM/DTCM by just memcpy operation. The MCUBoot FW after copy them to the target address is going to execute first bootable image.

As an example 3 images can be concatenated as

Simply tested with Zephyr on MAX32690EVKIT

Performance test output for 3 images: As summary this method clearly decrease boot time. Please see:

[ozersa]

This is really not at all how MCUboot is designed to operate, if you want this then you should use the hooks MCUboot has to run your functions for doing this in your own application or module

@nordicjm thanks for the feedback. While adding this feature we have not change behavior of mcuboot. It is just extended. Isn't it be useful for anyone else? Especially for multi core heterogenous systems. It helps to to decrease boot time & simplify fw update due to there is one main package that need to be managed.

[mehmetariman]

This is really not at all how MCUboot is designed to operate, if you want this then you should use the hooks MCUboot has to run your functions for doing this in your own application or module

@nordicjm thanks for the feedback. While adding this feature we have not change behavior of mcuboot. It is just extended. Isn't it be useful for anyone else? Especially for multi core heterogenous systems. It helps to to decrease boot time & simplify fw update due to there is one main package that need to be managed.

@nordicjm

I find this feature useful for bundling multiple images into single envelope so that it can decrease the authentication burden. We may have a discussion on how to infuse it better for the architecture. Yet, adding a hook for tailoring is not the main purpose. The main purpose is to add capability of bundling multiple packs into single image for verification which enhances performance in MCUBoot in general.

[nordicjm]

This is really not at all how MCUboot is designed to operate, if you want this then you should use the hooks MCUboot has to run your functions for doing this in your own application or module

@nordicjm thanks for the feedback. While adding this feature we have not change behavior of mcuboot. It is just extended. Isn't it be useful for anyone else? Especially for multi core heterogenous systems. It helps to to decrease boot time & simplify fw update due to there is one main package that need to be managed.

You have taken a mode and completely made up an entirely new container format without any discussion or thought about other MCUboot modes, security, previous version compatibility or design queries or how other supported OS's would implement such a feature notwithstanding a complete lack of documentation. Not to say that such a feature cannot be added, but this is really not at all the correct way to do it

[ozersa]

This is really not at all how MCUboot is designed to operate, if you want this then you should use the hooks MCUboot has to run your functions for doing this in your own application or module

@nordicjm thanks for the feedback. While adding this feature we have not change behavior of mcuboot. It is just extended. Isn't it be useful for anyone else? Especially for multi core heterogenous systems. It helps to to decrease boot time & simplify fw update due to there is one main package that need to be managed.

You have taken a mode and completely made up an entirely new container format without any discussion or thought about other MCUboot modes, security, previous version compatibility or design queries or how other supported OS's would implement such a feature notwithstanding a complete lack of documentation. Not to say that such a feature cannot be added, but this is really not at all the correct way to do it

@nordicjm We tried to add it without changing existing feature as possible as, There might be some items that we missed. We are eager to refactor it as per of your and maintainers feedback and direction to handle it in appropriate way. Please let me know which flow should we follow or which changes should we apply in this PR. Thanks for your support.

[d3zd3z]

You have taken a mode and completely made up an entirely new container format without any discussion or thought about other MCUboot modes, security, previous version compatibility or design queries or how other supported OS's would implement such a feature notwithstanding a complete lack of documentation. Not to say that such a feature cannot be added, but this is really not at all the correct way to do it

I do think this is a useful/valuable enough of a feature to have the discussion now and figure out how to implement this properly. One thing is that I don't think this should be a "fixup" that runs after the existing ramload runs, but that the ramload should be extended to support subimages. See my earlier comment, and please add any other concerns you have. My proposal is mainly to add a header flag to indicate the subimages, to make sure this functionality is behind a feature, but that the implementation within the feature is separate from the header flag (e.g., if the feature is present, but subimages is indicated in the header, reject the image entirely and fail to boot).

[d3zd3z]

I'm going to let CI run. If this passes that indicates we actually have a missing test coverage, as the case of a single image that is ramloaded should definitely be tested in the simulator, and this change, as it is, appears to break that.

[nordicjm]

You have taken a mode and completely made up an entirely new container format without any discussion or thought about other MCUboot modes, security, previous version compatibility or design queries or how other supported OS's would implement such a feature notwithstanding a complete lack of documentation. Not to say that such a feature cannot be added, but this is really not at all the correct way to do it

I do think this is a useful/valuable enough of a feature to have the discussion now and figure out how to implement this properly. One thing is that I don't think this should be a "fixup" that runs after the existing ramload runs, but that the ramload should be extended to support subimages. See my earlier comment, and please add any other concerns you have. My proposal is mainly to add a header flag to indicate the subimages, to make sure this functionality is behind a feature, but that the implementation within the feature is separate from the header flag (e.g., if the feature is present, but subimages is indicated in the header, reject the image entirely and fail to boot).

I don't think this should be added to RAM load at all, if you want sub-images, sure, made a system whereby it works for all modes, extending one mode without supporting the others is just the pinnacle of bad/lack of design

[nordicjm]

And something else I would say is this can be done using multiple image slots already, so why we need a duplicate secluded feature for what is already (and has been for years) supported today?

[ozersa]

And something else I would say is this can be done using multiple image slots already, so why we need a duplicate secluded feature for what is already (and has been for years) supported today?

@nordicjm sorry i might missed it but not see it is supported yet. How existing multi image feature support it? For example how user can authenticate 3 images with one signature check? Without applying a custom solution.

As an example it has been handled by TF-M with a custom solution, by adding a wrapper.py file and it is called with a Cmake command to concatenate images and execute one time signature check.

Thanks for the feedback.

[nordicjm]

As an example it has been handled by TF-M with a custom solution

TF-M does it's own things, I wouldn't trust that for a source of information on how to use MCUboot. Use this diff:

diff --git a/dts/vendor/nordic/nrf52840_partition.dtsi b/dts/vendor/nordic/nrf52840_partition.dtsi
index 1fa90a3ed71..7ffc5dd7878 100644
--- a/dts/vendor/nordic/nrf52840_partition.dtsi
+++ b/dts/vendor/nordic/nrf52840_partition.dtsi
@@ -25,12 +25,22 @@
 
 		slot0_partition: partition@c000 {
 			label = "image-0";
-			reg = <0x0000C000 0x00076000>;
+			reg = <0x0000C000 0x0003b000>;
 		};
 
-		slot1_partition: partition@82000 {
+		slot1_partition: partition@47000 {
 			label = "image-1";
-			reg = <0x00082000 0x00076000>;
+			reg = <0x00047000 0x0003b000>;
+		};
+
+		slot2_partition: partition@82000 {
+			label = "image-2";
+			reg = <0x00082000 0x0003b000>;
+		};
+
+		slot3_partition: partition@bd000 {
+			label = "image-3";
+			reg = <0x000bd000 0x0003b000>;
 		};
 
 		/*

Then build samples/subsys/mgmt/mcumgr/smp_svr for nrf52840dk/nrf52840 using Sysbuild with: -DFILE_SUFFIX="ram_load" -Dsmp_svr_CONFIG_UPDATEABLE_IMAGE_NUMBER=2 -Dsmp_svr_CONFIG_MCUMGR_GRP_IMG_UPDATABLE_IMAGE_NUMBER=2 -Dmcuboot_CONFIG_UPDATEABLE_IMAGE_NUMBER=2

[ozersa]

As an example it has been handled by TF-M with a custom solution

TF-M does it's own things, I wouldn't trust that for a source of information on how to use MCUboot. Use this diff:

diff --git a/dts/vendor/nordic/nrf52840_partition.dtsi b/dts/vendor/nordic/nrf52840_partition.dtsi
index 1fa90a3ed71..7ffc5dd7878 100644
--- a/dts/vendor/nordic/nrf52840_partition.dtsi
+++ b/dts/vendor/nordic/nrf52840_partition.dtsi
@@ -25,12 +25,22 @@
 
 		slot0_partition: partition@c000 {
 			label = "image-0";
-			reg = <0x0000C000 0x00076000>;
+			reg = <0x0000C000 0x0003b000>;
 		};
 
-		slot1_partition: partition@82000 {
+		slot1_partition: partition@47000 {
 			label = "image-1";
-			reg = <0x00082000 0x00076000>;
+			reg = <0x00047000 0x0003b000>;
+		};
+
+		slot2_partition: partition@82000 {
+			label = "image-2";
+			reg = <0x00082000 0x0003b000>;
+		};
+
+		slot3_partition: partition@bd000 {
+			label = "image-3";
+			reg = <0x000bd000 0x0003b000>;
 		};
 
 		/*

Then build samples/subsys/mgmt/mcumgr/smp_svr for nrf52840dk/nrf52840 using Sysbuild with: -DFILE_SUFFIX="ram_load" -Dsmp_svr_CONFIG_UPDATEABLE_IMAGE_NUMBER=2 -Dsmp_svr_CONFIG_MCUMGR_GRP_IMG_UPDATABLE_IMAGE_NUMBER=2 -Dmcuboot_CONFIG_UPDATEABLE_IMAGE_NUMBER=2

I am not sure i get the trick in here, there are 4 slots and and you specify 2 of them are updatable, isn't it means at least there will be two times signature check?

Additionally the proposal in this PR is just an extension to increase content of the project not changes existing MCUboot behaviour. By contributing this project we are trying to make it better without breaking/changing existing features.

[nordicjm]

As an example it has been handled by TF-M with a custom solution

TF-M does it's own things, I wouldn't trust that for a source of information on how to use MCUboot. Use this diff:

diff --git a/dts/vendor/nordic/nrf52840_partition.dtsi b/dts/vendor/nordic/nrf52840_partition.dtsi
index 1fa90a3ed71..7ffc5dd7878 100644
--- a/dts/vendor/nordic/nrf52840_partition.dtsi
+++ b/dts/vendor/nordic/nrf52840_partition.dtsi
@@ -25,12 +25,22 @@
 
 		slot0_partition: partition@c000 {
 			label = "image-0";
-			reg = <0x0000C000 0x00076000>;
+			reg = <0x0000C000 0x0003b000>;
 		};
 
-		slot1_partition: partition@82000 {
+		slot1_partition: partition@47000 {
 			label = "image-1";
-			reg = <0x00082000 0x00076000>;
+			reg = <0x00047000 0x0003b000>;
+		};
+
+		slot2_partition: partition@82000 {
+			label = "image-2";
+			reg = <0x00082000 0x0003b000>;
+		};
+
+		slot3_partition: partition@bd000 {
+			label = "image-3";
+			reg = <0x000bd000 0x0003b000>;
 		};
 
 		/*

Then build samples/subsys/mgmt/mcumgr/smp_svr for nrf52840dk/nrf52840 using Sysbuild with: -DFILE_SUFFIX="ram_load" -Dsmp_svr_CONFIG_UPDATEABLE_IMAGE_NUMBER=2 -Dsmp_svr_CONFIG_MCUMGR_GRP_IMG_UPDATABLE_IMAGE_NUMBER=2 -Dmcuboot_CONFIG_UPDATEABLE_IMAGE_NUMBER=2

I am not sure i get the trick in here, there are 4 slots and and you specify 2 of them are updatable, isn't it means at least there will be two times signature check?

Yes? That is no different than if you are verifying mode data, the time taken is going to increase if you are hashing/verifying the signature of a larger data size

Additionally the proposal in this PR is just an extension to increase content of the project not changes existing MCUboot behaviour. By contributing this project we are trying to make it better without breaking/changing existing features.

But as shown above this feature is 100% supported as-is today, the same way it is supported in other MCUboot modes, so what is improved by adding duplicate functionality that is going to have to be maintained by me, @de-nordic and @d3zd3z and is a starch difference for one specific mode of operation?

[nordicjm]

Also note that your changes here completely break things like MCUmgr because you're hiding data of multiple images in one image, you no longer know what gets loaded where

[ozersa]

As an example it has been handled by TF-M with a custom solution

TF-M does it's own things, I wouldn't trust that for a source of information on how to use MCUboot. Use this diff:

diff --git a/dts/vendor/nordic/nrf52840_partition.dtsi b/dts/vendor/nordic/nrf52840_partition.dtsi
index 1fa90a3ed71..7ffc5dd7878 100644
--- a/dts/vendor/nordic/nrf52840_partition.dtsi
+++ b/dts/vendor/nordic/nrf52840_partition.dtsi
@@ -25,12 +25,22 @@
 
 		slot0_partition: partition@c000 {
 			label = "image-0";
-			reg = <0x0000C000 0x00076000>;
+			reg = <0x0000C000 0x0003b000>;
 		};
 
-		slot1_partition: partition@82000 {
+		slot1_partition: partition@47000 {
 			label = "image-1";
-			reg = <0x00082000 0x00076000>;
+			reg = <0x00047000 0x0003b000>;
+		};
+
+		slot2_partition: partition@82000 {
+			label = "image-2";
+			reg = <0x00082000 0x0003b000>;
+		};
+
+		slot3_partition: partition@bd000 {
+			label = "image-3";
+			reg = <0x000bd000 0x0003b000>;
 		};
 
 		/*

Then build samples/subsys/mgmt/mcumgr/smp_svr for nrf52840dk/nrf52840 using Sysbuild with: -DFILE_SUFFIX="ram_load" -Dsmp_svr_CONFIG_UPDATEABLE_IMAGE_NUMBER=2 -Dsmp_svr_CONFIG_MCUMGR_GRP_IMG_UPDATABLE_IMAGE_NUMBER=2 -Dmcuboot_CONFIG_UPDATEABLE_IMAGE_NUMBER=2

I am not sure i get the trick in here, there are 4 slots and and you specify 2 of them are updatable, isn't it means at least there will be two times signature check?

Yes? That is no different than if you are verifying mode data, the time taken is going to increase if you are hashing/verifying the signature of a larger data size

Regarding your this concern, I just executed a test.

• Generated 3 images and signed them with imgtool
• For same images executed below tests both for method proposed here and with existing multi image feature in MCUboot. Depend on the my test result, for 3 same images the method proposed here is ~2times faster. So I clearly can say that this is valuable improvement for boot time. Please see detail in below screenshot.

[nordicjm]

As an example it has been handled by TF-M with a custom solution

TF-M does it's own things, I wouldn't trust that for a source of information on how to use MCUboot. Use this diff:

diff --git a/dts/vendor/nordic/nrf52840_partition.dtsi b/dts/vendor/nordic/nrf52840_partition.dtsi
index 1fa90a3ed71..7ffc5dd7878 100644
--- a/dts/vendor/nordic/nrf52840_partition.dtsi
+++ b/dts/vendor/nordic/nrf52840_partition.dtsi
@@ -25,12 +25,22 @@
 
 		slot0_partition: partition@c000 {
 			label = "image-0";
-			reg = <0x0000C000 0x00076000>;
+			reg = <0x0000C000 0x0003b000>;
 		};
 
-		slot1_partition: partition@82000 {
+		slot1_partition: partition@47000 {
 			label = "image-1";
-			reg = <0x00082000 0x00076000>;
+			reg = <0x00047000 0x0003b000>;
+		};
+
+		slot2_partition: partition@82000 {
+			label = "image-2";
+			reg = <0x00082000 0x0003b000>;
+		};
+
+		slot3_partition: partition@bd000 {
+			label = "image-3";
+			reg = <0x000bd000 0x0003b000>;
 		};
 
 		/*

Then build samples/subsys/mgmt/mcumgr/smp_svr for nrf52840dk/nrf52840 using Sysbuild with: -DFILE_SUFFIX="ram_load" -Dsmp_svr_CONFIG_UPDATEABLE_IMAGE_NUMBER=2 -Dsmp_svr_CONFIG_MCUMGR_GRP_IMG_UPDATABLE_IMAGE_NUMBER=2 -Dmcuboot_CONFIG_UPDATEABLE_IMAGE_NUMBER=2

I am not sure i get the trick in here, there are 4 slots and and you specify 2 of them are updatable, isn't it means at least there will be two times signature check?

Yes? That is no different than if you are verifying mode data, the time taken is going to increase if you are hashing/verifying the signature of a larger data size

Regarding your this concern, I just executed a test.

* Generated 3 images and signed them with imgtool

* For same images executed below tests both for method proposed here and with existing multi image feature in MCUboot.
  Depend on the my test result, for 3 same images the method proposed here is ~2times faster. So I clearly can say that this is valuable improvement for boot time. Please see detail in below screenshot.

Then profile the code and submit optimisations for what is slow. Adding this duplicate method is unacceptable in any form, in my opinion

[jockebech]

Then profile the code and submit optimisations for what is slow. Adding this duplicate method is unacceptable in any form, in my opinion

I doubt that will help / be possible. Hashing everything individually per partition or doing it all in one go will add up to take the same amount of time. It's the signature verification that is costly, so the more of them you do, the longer it'll take.

[de-nordic]

The right way to time this would be to time the signature verification and show separate timings in output.

There is already an issue that you have to be able to load entire image to RAM to even cut it into pieces (that is what the "Image 0 loaded from the primary slot" does in your log). If image0 RAM is not big enough to cover all images, this is it, you are not going anywhere.

[ozersa]

The right way to time this would be to time the signature verification and show separate timings in output.

There is already an issue that you have to be able to load entire image to RAM to even cut it into pieces (that is what the "Image 0 loaded from the primary slot" does in your log). If image0 RAM is not big enough to cover all images, this is it, you are not going anywhere.

Correct, the entire package must fit into RAM. Depending on the user use case,

• if it fits in RAM, it adds value to the system.
• If it doesn’t, users can use the existing independent multi-image feature.

Again this is an extension, not a replacement for the current functionality.

[ozersa]

@d3zd3z could you revisit? Thanks.

[nordicjm]

My original NACK on this stands, fyi.

[ozersa]

My original NACK on this stands, fyi.

Thanks for comment, is there a way to address your concern, might be refactor...?

[nordicjm]

My original NACK on this stands, fyi.

Thanks for comment, is there a way to address concern, might be refactor...?

See comment in https://github.com/mcu-tools/mcuboot/pull/2465#issuecomment-3350195519 You have designed your own system not paying attention to how MCUboot operates or with care to things like the image header, nor with any care to it's supported firmware update system over MCUmgr, hiding images inside of another image completely obscures them. As said, this should have been opened as an RFC without any code to discuss it, at which point this would have been pointed out

[ozersa]

My original NACK on this stands, fyi.

Thanks for comment, is there a way to address concern, might be refactor...?

See comment in #2465 (comment) You have designed your own system not paying attention to how MCUboot operates or with care to things like the image header, nor with any care to it's supported firmware update system over MCUmgr, hiding images inside of another image completely obscures them. As said, this should have been opened as an RFC without any code to discuss it, at which point this would have been pointed out

Just created RFC, please see: https://github.com/mcu-tools/mcuboot/issues/2525

[mehmetariman]

My original NACK on this stands, fyi.

Thanks for comment, is there a way to address concern, might be refactor...?

See comment in #2465 (comment) You have designed your own system not paying attention to how MCUboot operates or with care to things like the image header, nor with any care to it's supported firmware update system over MCUmgr, hiding images inside of another image completely obscures them. As said, this should have been opened as an RFC without any code to discuss it, at which point this would have been pointed out

@nordicjm

I believe the design is not set stone until PR is merged. To this end, I suggest leaving the original claim and existing work behind. Then open up the forum for discussion to see whether a feature like this will extend and enhance the feature-set of MCUBoot.

From your comments, what I see is you want a feature to scale across entire stack and stay away from being focused on one mode which makes sense.

The problem statement:

• The images generated with MCUBoot for the same system coming from same author need to go through separate signature check process. This increases the boot time when flat architecture is embraced.

The proposed feature is:

• Aggregate the flat images coming from the same author so that the signature overhead is reduced for the boot time.

The challenge I see:

• How to scale this across MCUBoot
• How to mitigate boot time configuration of checks in the MCUBoot: MCUBoot marks the checks needed at compile time and if any of the pre-defined checks are not present it is failing the boot.

The proposed solution has signature outside, yet it does not necessarily have signature for the images within the envelope. To this end, would it be useful to add run-time configuration of checks within the envelope that would be a subset of compile time checks.

With maintainers expertise and vision, I would be glad to see such feature integrated into MCUBoot as heterogenous cores, multi-core applications, containerized systems, and multi-image applications are getting into more applications.

This discussion can be moved to thread @ozersa created, or it can be brainstormed in a meeting of MCUBoot Forum.

Thanks a lot for your valuable constructive feedback in advance for the matter!

[nordicjm]

Here are some links with things for you to study:

• https://docs.mcuboot.com/design.html#image-format (the whole document, and other pages on the doc site)
• https://docs.mcuboot.com/encrypted_images.html
• https://github.com/mcu-tools/mcuboot/blob/main/boot/bootutil/include/bootutil/image.h#L167
• https://github.com/zephyrproject-rtos/zephyr/blob/main/subsys/dfu/img_util/flash_img.c#L26
• https://github.com/zephyrproject-rtos/zephyr/blob/main/subsys/dfu/boot/mcuboot.c
• https://github.com/zephyrproject-rtos/zephyr/blob/main/subsys/mgmt/mcumgr/grp/img_mgmt/src/img_mgmt.c
• https://github.com/zephyrproject-rtos/zephyr/blob/main/subsys/mgmt/mcumgr/grp/img_mgmt/src/img_mgmt_state.c
• https://github.com/apache/mynewt-mcumgr/tree/master/cmd/img_mgmt (the original MCUmgr code)

From there I suggest you look into things like the image structure, the fields in the image header, how image identification works, how image updates and uploads work. Then bearing in mind the following requirements:

• System should not break how existing bootloaders work or cause them to malfunction
• MCUboot header size shall not be changed
• MCUmgr support must be maintained including support for existing builds of firmware and new firmware should not break how it functions on those devices
• Information available for things like where images should be loaded must not be buried part the way through firmware
• Other features should remain fully functional and remain secure e.g. monotonic counter support, encrypted image support
• Feature should be usable (not that support needs adding for it in the addition PR, but that support could be made to other RTOS's if other users wanted to) on any RTOS/OS
• Be mindful that MCUboot should be optimised for constrained devices and not use excessive flash/RAM, not that usage cannot increase but it should not increase by a large amount that prevents usage on commonly supported (and used) devices

With the above in mind, please have a think and update your RFC with your proposed solution for this which meets the above requirements and I shall review it, thanks!

[d3zd3z]

We discussed this change today during the tech call. The basic conclusion we came to can be summarized as:

• There is value in multiple image support, however this implementation does not fit well with the rest of MCUboot.
• There are two approaches we can take to multiple image support:
  • Add a new signature type that can cover multiple images. This is fairly invasive, and only solves the minor problem of signature verification time.
  • Allow a richer image type that supports loading a single image into possibly multiple areas of RAM.
• The best approach, then, is likely to be adding support for richer images. However, it needs to be implemented in a way that works with MCUboot.
• There is an existing TOCTOU vulnerability in ram loading, where the signature is validated, and then in a separate pass the image is loaded into RAM. To fix this, the image validation needs to be combined with the image loading as a single pass. This will need to be fixed before this multiple image support should be added.
• Then with this new loader, it can be enhanced to support these multiple images. To do this, the file format of the extended image should be clearly defined and documented, and discussed, perhaps in some kind of RFC change that just adds the documentation. We will need some time to review this and consider issues.
• When using multiple images, there is no reason to have headers on the individual images, they can just be the start of the OS image. This actually applies even to single images, so a "multiple-image" that has a single image in it makes sense, and allows MCUboot, in configurations that ram load, to not need any modification in the target OS to support or work around the header.
• The implementation should then clearly be defined in two ways:
  • There should be a change to the regular image header, perhaps a flag bit, to indicate that the image is a "rich image" or something similar. This has a defined format, either with a single header at the start, or more likely, individual headers before each segment.
  • This needs to be done in such a way that the loader can process both the signature as it loads, as well as placing them in the correct destinations within RAM. There can be a feature in MCUboot to enable this rich image support, but it would only be for code-size, as the load would need to continue to support the current plain images as well.
• As a simple workaround, the authors of this change could consider disabling image verification on each boot. The image signatures would still be verified when doing upgrades, but not on every boot. This still has some security, as presumably the internal flash is reasonably protected (and if it isn't mcuboot itself could be modified to bypass security).
• In addition, each change/pr that implements this needs to have support added to the simulator to both verify that the existing use cases are not broken, and to verify that the rich images are being handled properly.