github/linuxkit
1
0
Fork 0
mirror of https://github.com/linuxkit/linuxkit.git synced 2025-07-20 09:39:08 +00:00
Code Issues Projects Releases Wiki Activity

Merge pull request #1407 from avsm/miragesdk-readme

Browse Source 
miragesdk: more tweaks to README markdown
This commit is contained in:
Anil Madhavapeddy 2017-03-28 22:20:18 +01:00 committed by GitHub
commit df33c8a4d3
1 changed files with 8 additions and 8 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

16
projects/miragesdk/README.md
View File

@ -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