From 5c9d5315e56970939ebbabee500c9fe147e521ef Mon Sep 17 00:00:00 2001 From: Anil Madhavapeddy Date: Tue, 28 Mar 2017 22:07:15 +0100 Subject: [PATCH] miragesdk: more tweaks to README markdown Signed-off-by: Anil Madhavapeddy --- projects/miragesdk/README.md | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/projects/miragesdk/README.md b/projects/miragesdk/README.md index 874f89a7e..460e2fc65 100644 --- a/projects/miragesdk/README.md +++ b/projects/miragesdk/README.md @@ -8,12 +8,12 @@ as DHCP, NTP or DNS, with the following properties: - run in a container as a single static binary. - follow a common configuration convention based on bind mounts from the host. - obey strict security conventions: - - the container has the minimal capabilities required to execute. - - after configuration is read, the service privilege separates itself to drop as much as possible. - - processes use KVM to supply extra hardware protection if available, via the Solo5 unikernel. - - if KVM is not available, use seccomp-bpf to restrict the set of syscalls used. - - all untrusted network traffic must be handled in memory-safe languages. - - support automated fuzz testing so that tools like AFL can run regularly to detect bugs proactively. + * the container has the minimal capabilities required to execute. + * after configuration is read, the service privilege separates itself to drop as much as possible. + * processes use KVM to supply extra hardware protection if available, via the Solo5 unikernel. + * if KVM is not available, use seccomp-bpf to restrict the set of syscalls used. + * all untrusted network traffic must be handled in memory-safe languages. + * support automated fuzz testing so that tools like AFL can run regularly to detect bugs proactively. The SDK will initially support OCaml (via MirageOS), and later expand to cover Rust. Depending on community interest, we may expand the set of supported @@ -44,9 +44,9 @@ the hardware support is available. privilege separate due the deep (and non-portable) system hooks required for handling IP and routing tables (e.g. via `RT_NETLINK`). Thus this implementation flushes out a lot of architectural questions and makes subsequent protocol implementations such - as HTTPS or NTP more straightforward. See [why-dhcp.md](why-dhcp.md) for more details. + as HTTPS or NTP more straightforward. See [why-dhcp](why-dhcp.md) for more details. -- The [roadmap](roadmap.md) describes the architecture of the DHCP client and current +- The **[roadmap](roadmap.md)** describes the architecture of the DHCP client and current development directions. - We are also packaging up the Alpine `dhcpcd` with the same configuration conventions