From what I've said, would there be any problems with including my
Hi Andrew,
Sorry for the late reply on this one!
The boot code of seL4 is currently unverified, but we do have ambitions for verification in the future. As such, we'd want to keep a minimal, static boot environment. That said, we'd be more than happy to take a look at any patches you have in more detail.
I'm curious as to why you need to place your desired functionality into the boot loader, rather than at user level in a root task or some kind of chain loader? How much trust is placed into your boot loader?
When you say "implement a full disk-based bootloader" -- this would be at user-level, right? We definitely don't want to have to trust disk drivers to boot seL4 + the root task.
Our current image format (cpio) is one picked for convenience/simplicity and we'd be more than happy to consider proposals for a different format. MBI passthrough is a desirable feature.
Cheers,
Anna.
________________________________________
From: Devel on behalf of Andrew Warkentin
Sent: Monday, 1 October 2018 6:26 PM
To: devel@sel4.systems
Subject: [seL4] Support for QNX-like booting from an XIP filesystem image
For UX/RT https://gitlab.com/uxrt/, the seL4-based OS I am writing, I
have patched seL4 to support for booting from an in-memory execute-in-place
filesystem image that contains the kernel and all user-mode programs
required to mount the root filesystem (similar to that of QNX, but
with more of the
functionality in the bootloader rather than the root server). The existing
seL4 boot process may be OK for static embedded systems that are always
cross-compiled, but UX/RT is going to be a dynamic general-purpose OS with
a boot image that will include files from multiple
separately-installed packages and
will possibly be customized to the system it is installed on.
Requiring any image
filesystem to be linked into the root server makes updating boot images
more complex than being able to use a simple filesystem builder to make an
image containing the kernel, root server, and everything else that is
required (the main special considerations being placing the kernel and root
server at fixed physical addresses and padding the image to allow for bss
sections, which are easy enough). Also, I want it to be easy to manually
boot UX/RT images, so you can just type something like "boot
(hd0,0)/uxrt.boot" (much like manually booting NetBSD, OpenBSD, or most
older Unices), and the bootloader will automatically load the kernel and
all required modules from within the image as opposed to having to type a
lot of boilerplate to load the kernel and root server (and anything else
that may be required). In addition I don't think that the root server
should need to have any support for parsing image filesystems and
should be able to obtain all the files required for early boot from
the MBI.
I am using Multiboot2 with a few custom tags added and a few extra
requirements regarding placement of modules. I currently have an
in-memory loader that implements my variant of Multiboot2, and
eventually want to
implement a full disk-based bootloader. I have also implemented a
page-oriented in-memory filesystem called XRFS (originally based on
Linux romfs) with support for placing files at fixed addresses. The
in-memory loader was parsing the filesystem and using a script to
locate the modules within the image, although I have decided that it
is overkill to do that, and it would allow the loader to be simpler if
the filesystem image has its own MBH separate from that of the kernel
(the magic number will be different from the kernel MBH as well), with
tags for the kernel and each module, so that the loader's existing
MBH-parsing code can be used to locate files in the image.
As far as my kernel patches go, they extend the existing Multiboot2
code and do not interfere with the existing boot code. Right now they
are x86-only, but I am planning to add Multiboot2 support to other
architectures eventually as well. They do not introduce any dependency
on my filesystem format in the kernel (it does know that there is an
FS image and that there are modules contained within it, and assumes
that modules are contiguous). Relocation of the root task is disabled
when an FS image is present, since it will already be placed in a
usable location in the image. Kernel-level ELF loading of modules is
also disabled when using my Multiboot2 extensions, since my loader is
capable of parsing ELF modules, loading them, and passing information
on module sections and addresses to the kernel through tags. The part
of the image containing the kernel is inaccessible to the root task
for obvious reasons, so an additional requirement is that the kernel
is the first file in the image, followed by the root server, and then
all other files (XRFS is structured to allow the remainder of the
image to be read even though the beginning is inaccessible). There is
also support for passing the MBI through to the root task, which
requires that the MBI is allocated immediately after the end of the
filesystem image (a new structure is added to the bootinfo to provide
the root server with the address of the MBI).
patches in the mainline seL4 repository? Only the boot code is
modified. Loading the root server works, but I haven't yet tested the
MBI passthrough, so I am not quite ready to submit anything (currently
I am working on converting my bootloader from parsing the filesystem
itself to parsing an MBH in the FS image, like I said before).
_______________________________________________
Devel mailing list
Devel@sel4.systems
https://sel4.systems/lists/listinfo/devel
