Using Xous as a secure bootloader

[arturkow2000]

Hello

We are interested in using Xous as a secure bootloader in the Fobnail project. Mainly on RISC-V platforms, however if Xous had support for x86 and architectures we would consider using it there too. Do you plan to add support for architectures other than RISC-V? We saw there is already a dummy x86 implementation, do you plan to extend it?

We'd like to use it as mini OS that would communicate with a device called Fobnail Token in order verify integrity of the target OS and boot it if verification passes.

We need the following things

• OS ability to run on multiple platforms without recompiling
• USB host drivers with USB EEM driver and network stack
• TPM support
• support for C interface to kernel, together with standard C library
• ability to chainload another OS - ability for a privileged service to execute
  code in kernel mode

Do you plan to implement this? Could you also take a look at our research regarding Xous, is there anything more we should know about?

[pietrushnic]

I believe it is worth to mention that Fobnail Project is sponsored by NLNet and there are some USB token companies interested in including feature in their produce. Even if initially Xous would not be supported by Fobnail Project maybe there could be a value to create in long term for some workloads. We envision various DLME OSes for various use cases. I assume sooner or later RISC-V will gain D-RTM capabilities, it is probably matter of correct implementation (probably in SBI 🤔 ) - at least other architectures x86 (both Intel and AMD), Arm (recently published spec) and OpenPOWER (my presentation from tpm.dev miniconf) already have some support for D-RTM.

[xobs]

Thanks for the interest in Xous!

The kernel was designed with other architectures in mind. The requirements for a Xous port are as follows:

• Memory management unit
• The ability to have 8 arguments when making syscalls

I believe x86 should be able to satisfy both requirements.

We already support some variant of "x86" in that "hosted" mode is actually another architecture entirely. On RISC-V we pass arguments to and from the kernel using 8 usize-sized registers. On "hosted" we pass them in 8 u32-sized words in a TCP packet.

To address your requirements in-order:

• OS ability to run on multiple platforms without recompiling: I'm not sure what this requirement means. Since it's machine code and not a bytecode, you will need to recompile when porting between platforms. However, with Rust this does not require a different toolchain since all architectures are supported by the compiler.
• USB host drivers with USB EEM driver and network stack Our network stack is provided by messages that get passed to the net Server. The network stack is backed by smoltcp. This server could get swapped out for your own version that provides the networking glue you require.
• TPM support: I'm not sure what this entials or what you consider to be a "TPM". On Betrusted, all trusted blocks are memory-mapped and are handled by their respective Servers. If you have an off-chip TPM this would be handled by a Server that controls the communications interface.
• support for C interface to kernel, together with standard C library: We do not have a standard C library, and have worked very hard to ensure our users do not require a C compiler in order to use Xous. Having said that, the basic Xous primitives of "Connect to a Server" should be trivial to port to C. Likewise, putc() should be easy to bring up using the log-server as a console output. However, this is not something we have done.
• ability to chainload another OS - ability for a privileged service to execute
  code in kernel mode: This could be implemented with an additional syscall. Because it's such an invasive syscall I'd prefer to have it available as a compile-time option that gets stripped in Betrusted builds. This would also be a good time to add a Pledge() call that limits the available syscalls, so we can be super certain that processes won't ever be able to call it. However, it's not outside the realm of possibility that this would be added.