Deprecate MakeCPIO in favour of inlining binaries directly into elf files or into their final memory locations

[kent-mcleod]

The MakeCPIO function takes a list of files generates a archive.o binary containing an embedded cpio archive in its own section _archive_cpio with symbols _cpio_archive and _cpio_archive_end. This is used for embedding binaries in at least the following loaders:

• the elfloader uses it to store the kernel.elf and roottask binaries and also optionally some hashes of the included files.
• the capdl-loader-app uses it to store all the user binaries that it will load when initializing a system,
• the sel4test-driver app uses it to store any test process images it loads,
• the sel4benchapp application uses it to hold all benchmark process images it loads.
• the camkes vm project's fileserver uses it to hold kernel and rootfs images.

Problem: All current usages would benefit from being able to have the embedded binaries aligned to some page boundary. This would make copying faster as addresses are aligned better, but also for ELF files, it'd make it possible to directly map read-only segments from the original memory location. CPIO archives don't align their contents and so these embedded cpio archives always require unpacking the contents to a different memory location.

Proposal: Instead of a cpio archive ebedded in an object file, it'd be simpler to directly embed the internal file objects into the object file and for symbols to be declared for the start and end positions of the file.

This would remove the CPIO archive step in the embedding and allow images to be loaded at specific aligned addresses.

All that's required is for these projects to just move off of using the MakeCPIO utility and directly embed the files that they need at their compilation stage in their own CMake project files.

[Indanz]

I always thought the use of CPIO was a bit weird and unnecessarily complex for what's actually needed, but I assumed there originally was a reason to use CPIO.

CPIO is good for dynamic systems that don't know beforehand what files they need and actually need a filesystem of sorts. But then embedding the archive into an .o file seems to defeat the whole purpose.

[Indanz]

Proposal: Go one step further and get rid of Elfloader altogether (I mean, as requirement to boot seL4, it can stay for backward compatibility).

If the images are combined, it's trivial for seL4 itself to load the initial task and do whatever is required for booting up normally, like it does for x86. Arm and RISCV are simpler than x86, so I don't see any justification of the added complexity of using Elfloader.

There is some functionality like hashing etc. in Elfloader, but things like that are done better by a bootloader like U-Boot. And having seL4 be able to boot itself doesn't preclude adding another loader in front of it either.

Same for Microkit, its loader doesn't do anything useful that can't be done by the startup task once seL4 can load the initial task's ELF file itself.

[axel-h]

Are you volunteering to create a replacement? I think it's on the list for ages, but the priority is quite low. And most specific implementation sooner or later implement their own boot flow anyway that does not use the ElfLoader

[Indanz]

Yes, I am. I think it would simplify things a fair bit over all.

[Ivan-Velickovic]

@Indanz for hardware initialisation such as enabling the MMU, dropping into the right EL on ARM, bringing up cores etc, would you move that into the kernel boot code?

[Indanz]

@Indanz for hardware initialisation such as enabling the MMU, dropping into the right EL on ARM, bringing up cores etc, would you move that into the kernel boot code?

Yes. There isn't much else to do. I don't see anything in Microkit's loader that couldn't be done by either the kernel or the first task. And after this change, the difference between x86 and Arm/RISCV becomes smaller too.

[Ivan-Velickovic]

Yes. There isn't much else to do. I don't see anything in Microkit's loader that couldn't be done by either the kernel or the first task. And after this change, the difference between x86 and Arm/RISCV becomes smaller too.

Cool, sounds good.