You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: content/showcase/rusty-hermit/index.md
+58-38Lines changed: 58 additions & 38 deletions
Original file line number
Diff line number
Diff line change
@@ -6,73 +6,93 @@ date = 2021-01-17
6
6
authors = ["stlankes"]
7
7
+++
8
8
9
-
[RustyHermit](https://github.com/hermitcore/rusty-hermit) is a unikernel, which is completely written Rust. [Unikernel](http://unikernel.org/) are application images that directly contain the kernel as a library, so it does not require an installed operating system (OS). They are typical used in virtualized environments, which build the backbone of typical cloud / edge infrastructures.
9
+
[RustyHermit](https://github.com/hermitcore/rusty-hermit) is a unikernel, which is completely written Rust. [Unikernels](http://unikernel.org/) are application images that directly contain the kernel as a library, so they do not require an installed operating system (OS). They are typical used in virtualized environments, which build the backbone of typical cloud / edge infrastructures.
10
10
11
-
Common virtualized environment based on classical virtual machines. In this case, complete machines are emulated or virtualized and on host and guest site are running common operating systems. This technique is established (VMware, Hyper-V, etc.) and widely used. However, it introduces additional overhead especially regarding memory consumption and performance.
11
+
## Virtualization Designs
12
12
13
-
13
+
Common virtualized environment based on classical **_virtual machines_**. In this case, complete machines are emulated or virtualized and common operating systems are running on both host and guest site:
14
14
15
-
An alternative approach to common virtual machines is OS-level
16
-
virtualization, where the kernel allows the existence of multiple
15
+
16
+
17
+
This technique is established (VMware, Hyper-V, etc.) and widely used. However, it introduces additional overhead especially regarding memory consumption and performance.
18
+
19
+
An alternative approach to common virtual machines is **OS-level
20
+
virtualization**, where the kernel allows the existence of multiple
17
21
isolated user space instances. These isolated instances are also known
18
22
as container. A typical representative is LXC or Docker and promise less
19
23
overhead in comparison to common virtual machines. However, the
20
24
isolation between the processes is weaker and may provide less security.
21
25
22
-
Often only one application (e.g. a web server) is running in the container or the virtual machine. In this case, is a unikernel an attractive solution. The kernel is provided as static library and linked to the application. As the images directly contain the OS kernel, unikernels can directly be bootet inside a virtual machine and do not require the typical software stack containing a linux kernel and its userland within the VM.
26
+
## Unikernels
27
+
28
+
Often only one application (e.g. a web server) is running in the container or the virtual machine. In this case, a _unikernel_ is an attractive solution. The kernel is provided as static library and linked to the application. As the images directly contain the OS kernel, unikernels can directly be booted inside a virtual machine and do not require the typical software stack containing a Linux kernel and its userland within the VM.
23
29
24
-
Unikernels do not provide system calls in the classical sense, as everything is running with the privilege level of a kernel and what is typically done via system calls is provided via a common function call. At first glance, this sounds more insecure than previous approaches. However, these kernels are expected to run within a virtual machine, which isolated the application from the real system. In addition, common compiler analysis is used to check the complete software stack and even unneeded components can be removed, which can reduce the attack surface of the application.
30
+
Unikernels do not provide system calls in the classical sense, as everything is running with the privilege level of a kernel and what is typically done via system calls is provided via a common function call. At first glance, this sounds more insecure than previous approaches. However, these kernels are expected to run within a virtual machine, which isolates the application from the real system. In addition, common compiler analysis is used to check the complete software stack and unneeded components can even be removed, which can reduce the attack surface of the application.
25
31
26
-
32
+
27
33
28
34
Well known unikernels are kernels such as [MirageOS](https://mirage.io/)
29
35
and [Unikraft](http://www.unikraft.org/). MirageOS is written in OCaml,
30
-
while Unikraft still use C as programming language. In contrast to these
36
+
while Unikraft still uses C as programming language. In contrast to these
31
37
kernels, RustyHermit is completely written in Rust to benefit from
32
-
Rust's performance and security behavior. In principle, every existing
38
+
Rust's performance and security behavior.
39
+
40
+
## RustyHermit
41
+
42
+
In principle, every existing
33
43
Rust application can be built on top of RustyHermit. However, unikernels
34
44
are a single tasking operating system. Consequently, the support of the
35
45
system call `fork` and inter-process communication are missing. In
36
46
addition, a classical C library is missing, which is typical used as
37
-
interface to the operating system. Every crate, which bypass the
47
+
interface to the operating system. Every crate, which bypasses the
38
48
standard runtime and tries to communicate directly to operating system
39
49
does not work without modifications. However, many applications do not
40
50
depend on these features and work on RustyHermit.
41
51
52
+
### Performance
53
+
42
54
Unikernels can be highly optimized. For instance, we optimized the
43
55
network stack of RustyHermit. RustyHermit uses
44
56
[smoltcp](https://github.com/smoltcp-rs/smoltcp) as network stack, which
45
57
is completely written in Rust. As interface between guest and host
46
58
operating system, we use
47
59
[Virtio](https://www.linux-kvm.org/page/Virtio), which is in a
48
60
para-virtualized driver for KVM and widely used in virtualized Linux
49
-
environments. The following figure compares Linux with RustyHermit,
61
+
environments.
62
+
63
+
The following figure compares Linux with RustyHermit,
50
64
where both are running as guests inside a virtual machine running on top
51
-
of a Linux-based host system. Especially for small messages RustHermit
65
+
of a Linux-based host system:
66
+
67
+
68
+
69
+
Especially for small messages RustHermit
52
70
is faster in than Linux.
53
71
54
-
72
+
### Research
55
73
56
74
RustyHermit is also a research project to evaluate new operating
57
-
systems designs, which improves the scalability and the security of operating systems in cloud environments. For instance, RustyHermit provides classical
75
+
system designs, which improves the scalability and the security of operating systems in cloud environments. For instance, RustyHermit provides classical
58
76
techniques to improve the security behavior like stack guards and
59
-
separating the application stack from the libos stack. However, a
60
-
library operating system uses typical a common function call to enter
61
-
the kernel. A classical separation from user- and kernel space by
77
+
separating the application stack from the libOS stack. However, a
78
+
library operating system typically uses a common function call to enter
79
+
the kernel. A classical separation of user- and kernel space by
62
80
entering a higher privilege level is missing. We presented in a
63
-
[paper](https://www.ssrg.ece.vt.edu/papers/vee20-mpk.pdf) a modified
64
-
version of RustyHermit, which provides an intra-unikernel isolation with
65
-
Intel Memory Protection Keys (MPK). MPK is a relatively new hard-ware
66
-
primitive that provides per-thread permission control over groups of
67
-
pages in a single address space with [negligible switching overhead](https://www.usenix.org/conference/atc19/presentation/park-soyeon),
68
-
making it a compelling candidate for use in unikernels.
81
+
[paper](https://www.ssrg.ece.vt.edu/papers/vee20-mpk.pdf) a modified
82
+
version of RustyHermit, which provides an intra-unikernel isolation with
83
+
_Intel Memory Protection Keys_ (MPK). MPK is a relatively new hard-ware
84
+
primitive that provides per-thread permission control over groups of
85
+
pages in a single address space with [negligible switching overhead](https://www.usenix.org/conference/atc19/presentation/park-soyeon),
86
+
making it a compelling candidate for use in unikernels.
69
87
70
-
MPK is requiring modification of page tables at a small performance cost. Four previously-unused bits of each page table entry (the 62nd to the 59th on x86-64) are exploited by MPK. Since MPK exploits four bits of the page table entry, it supports up to 15 protection keys.
71
-
MPK controls per-thread permission on groups of pages. Each core has a PKRU register (32 bits) containing a permission value. The value of the PKRU register defines the permission of the thread currently running on that core for each group of pages containing a protection key in their page table entries. Unlike page-table-level permission, MPK provides thread-local memory permission.
88
+
MPK is requiring modification of page tables at a small performance cost. Four previously-unused bits of each page table entry (the 62nd to the 59th on x86-64) are exploited by MPK. Since MPK exploits four bits of the page table entry, it supports up to 15 protection keys.
89
+
MPK controls per-thread permission on groups of pages. Each core has a PKRU register (32 bits) containing a permission value. The value of the PKRU register defines the permission of the thread currently running on that core for each group of pages containing a protection key in their page table entries. Unlike page-table-level permission, MPK provides thread-local memory permission.
72
90
73
91
We provide user / kernel separation so we simply see the entire application as an untrusted component, independently of application-specific characteristics such as the language it is written in or the level of skill of the application’s programmer. In addition, we divide the kernel code into trusted and untrusted components. Trusted kernel components represent pieces of code written with a memory-safe language, i.e., offering strong security guarantees. Untrusted kernel components correspond to code written either in memory-unsafe languages or in unsafe Rust code blocks.
74
92
75
-
By entering the library operating system through the application binary interface, the protection keys will be automatically changed and allows access to the kernel stack and the kernel heap. Unauthorized access from within the application will trigger a pagefault, which will be handled by the library operating system.
93
+
By entering the library operating system through the application binary interface the protection keys will be automatically changed, which allows access to the kernel stack and the kernel heap. Unauthorized access from within the application will trigger a pagefault, which will be handled by the library operating system.
94
+
95
+
### Example Project
76
96
77
97
To give you an example on how to build an RustyHermit application, lets create a new cargo project:
78
98
@@ -84,11 +104,9 @@ cd hello_world
84
104
RustyHermit currently requires the nightly versions of the Rust toolchain.
85
105
To simplify the workflow, we recommend to create the configuration
86
106
_rust-toolchain_ as follows to define the required components and to
87
-
tested version of nightly compiler.
88
-
89
-
To simplify the workflow, we recommend that you create the _rust-toolchain_ configuration file as follows:
To bind the library operating system to the application, we have to add the crate [hermit-sys](https://crates.io/crates/hermit-sys) to the dependencies in the file `Cargo.toml`.
133
+
To bind the library operating system to the application, we have to add the crate [`hermit-sys`](https://crates.io/crates/hermit-sys) to the dependencies in the file `Cargo.toml`:
116
134
117
135
```toml
118
136
# Cargo.toml
@@ -130,7 +148,7 @@ Finally, the application can be build with the common command `cargo build`.
130
148
131
149
The result is a 64-bit excutable in the [executable link format](https://refspecs.linuxfoundation.org/elf/elf.pdf) (ELF).
132
150
To start the application within a common virtual machine, a loader is required, which initialize the processor and start the applications.
133
-
We provide at [GitHub](https://github.com/hermitcore/rusty-loader) a simple loader.
151
+
We provide a simple loader on [GitHub](https://github.com/hermitcore/rusty-loader).
134
152
A makefile to build the loader is part of the project.
135
153
After that, Qemu can be used to start RustyHermit in a VM as follows:
136
154
@@ -144,8 +162,10 @@ To improve the performance, KVM can be used to use the virtualization extension
0 commit comments