Enabling CHERIoT support in upstream libhydrogen

[PhilDay-CT]

As part of the TAP-6 work I now have a working port of the libhydrogen crypto library. I'd like to contribute that back upstream so that we can pull it in as a direct submodule, but there are couple of CHERIoT specific things that I need a steer on:

1. I need a #define value to know that it's being compiled for CHERIoT. What I currently have is:

#elif defined(_WIN32)
#    include "random/windows.h"
#elif defined(__wasi__)
#    include "random/wasi.h"
#elif defined(__linux__) && defined(__KERNEL__)
#    include "random/linux_kernel.h"
#elif defined(__unix__)
#    include "random/unix.h"
...
#elif defined(__cheriot__)
#    include "random/cheriot.h"

with the corresponding define in xmake.lua

on_load(function(target)
        target:add('options', "CHERIOT")
        local Cheriot = get_config("CHERIOT")
        target:add("defines", "__cheriot__=" .. tostring(Cheriot))
    end)

but if seems like the definition of "__cheriot__" (or something similar, I'm not fixed on the name) should be part of the base platform so we use it consistently in any other such use cases.

2. The conditional code that this includes has to initialise the libraries random number system, for which it needs a 32 bit random number. I have that abstracted into

   uint32_t rand_32();

which then implemented in my code as

#include <platform-entropy.hh>

extern "C" uint32_t rand_32()
{
	static EntropySource rng;
	uint64_t r = rng();
	uint32_t r32 = r & 0xffffffff;
	return r32;
}

but it feels like that should be moved into cheriot-rtos somewhere to avoid anyone else that wants to use libhydrogen from having to implement it. Where should it go, and is it OK to have something in say sdk/lib that is platform dependent when not all instances of include/platform seem to provide platform.entropy.hh ?

3. I have a simple compartment wrapper around libhydrogen (could become a library) which will currently end up back in cheriot-demos, but it feels like there probably should be somewhere similar to network-stack for holding reusable contributions like this (cheriot-utils ?). Any thoughts / plans for this ?

[davidchisnall]

For 1: The compiler provides a predefined macro for CHERIoT. You can use -dM -E -o - to make clang print all of the predefined macros. For example:

$ echo | /path/to/cheriot/clang++ -c -Qunused-arguments -target riscv32-unknown-unknown -mcpu=cheriot -mabi=cheriot -mxcheri-rvc -fshort-wchar -fvisibility=hidden -fvisibility-inlines-hidden -std=c++20 -x c++ - -dM -E -o - | grep -i cheri 
#define __CHERIOT__ 20241214
#define __CHERI_ADDRESS_BITS__ 32
#define __CHERI_CAPABILITY_TABLE__ 3
#define __CHERI_CAPABILITY_WIDTH__ 64
#define __CHERI_CAP_PERMISSION_ACCESS_SYSTEM_REGISTERS__ 1024
#define __CHERI_CAP_PERMISSION_GLOBAL__ 1
#define __CHERI_CAP_PERMISSION_PERMIT_EXECUTE__ 2
#define __CHERI_CAP_PERMISSION_PERMIT_INVOKE__ 256
#define __CHERI_CAP_PERMISSION_PERMIT_LOAD_CAPABILITY__ 16
#define __CHERI_CAP_PERMISSION_PERMIT_LOAD__ 4
#define __CHERI_CAP_PERMISSION_PERMIT_SEAL__ 128
#define __CHERI_CAP_PERMISSION_PERMIT_STORE_CAPABILITY__ 32
#define __CHERI_CAP_PERMISSION_PERMIT_STORE_LOCAL__ 64
#define __CHERI_CAP_PERMISSION_PERMIT_STORE__ 8
#define __CHERI_CAP_PERMISSION_PERMIT_UNSEAL__ 512
#define __CHERI_PURE_CAPABILITY__ 2
#define __CHERI__ 1
#define __SIZEOF_CHERI_CAPABILITY__ 8
#define __VERSION__ "Clang 17.0.0 (ssh://[email protected]/CHERIoT-Platform/llvm-project b3d674da29a5d28c217b79152b27d3cadc9d1dd5)"
#define __clang_version__ "17.0.0 (ssh://[email protected]/CHERIoT-Platform/llvm-project b3d674da29a5d28c217b79152b27d3cadc9d1dd5)"
#define __riscv_xcheri 0
#define __riscv_xcheri_mode_dependent_jumps 1

There's also a __CHERIOT_BAREMETAL__ define if you select the bare-metal ABI.

[davidchisnall]

For 2, I think we should add an entropy compartment that wraps the current entropy driver. Other things in the network stack provide their own rand implementations as well. Ideally, I'd like to have some better software whitening there as well (not sure if something like Fortuna would fit).

In a complete libhydrogen port, I think we'd like most of libhydrogen to be exposed as a library, which would mean that we could use libhydrogen's whitening code directly from the entropy compartment.

[PhilDay-CT]

To try and move this along a bit as its one of the things we said we'd do as part of our TAP funding:

on 2) adding an entropy compartment sounds like just shifts the problem of how to implement it when not all platforms seem to have a platform-entropy.hh. I guess we already have a pattern that the network-stack compartments can only be included on builds for platforms that have platform-ethernet. I can hide all of this and implement the rand_32() in a crypto compartment which then wraps libhydrogen, but that still leaves question 3) of where to try and land this (wherever it lands will bring in libhydrogen as a git submodule)

cheriot-rtos - which would reflect its wider applicability than just networking, but which doesn't AFAIK have any code that only runs on some platforms

network-stack - but although we're using it an network context, it doesn't feel like a great aligment

some new repos for cheriot add-ons ?