|
1 |
| -[](https://github.com/enarx/sev/actions?query=workflow%3A%22test%22) |
2 |
| -[](https://isitmaintained.com/project/enarx/sev "Average time to resolve an issue") |
3 |
| -[](https://isitmaintained.com/project/enarx/sev "Percentage of issues still open") |
4 |
| - |
5 |
| - |
6 | 1 | # sev
|
7 | 2 |
|
8 | 3 | The `sev` crate provides an implementation of [AMD Secure Encrypted
|
9 | 4 | Virtualization (SEV)](https://developer.amd.com/sev/) APIs.
|
10 | 5 |
|
11 |
| -The Linux kernel exposes two technically distinct AMD SEV APIs: |
12 |
| - |
13 |
| -1. An API for managing the SEV platform itself |
14 |
| -2. An API for managing SEV-enabled KVM virtual machines |
15 |
| - |
16 |
| -This crate implements both of those APIs and offers them to client |
17 |
| -code through a flexible and type-safe high level interface. |
18 |
| - |
19 |
| -### Platform Management |
20 |
| - |
21 |
| -Refer to the [`firmware`] module for more information. |
22 |
| - |
23 |
| -### Guest Management |
24 |
| - |
25 |
| -Refer to the [`launch`] module for more information. |
26 |
| - |
27 |
| -### Remarks |
28 |
| - |
29 |
| -Note that the Linux kernel provides access to these APIs through a set |
30 |
| -of `ioctl`s that are meant to be called on device nodes (`/dev/kvm` and |
31 |
| -`/dev/sev`, to be specific). As a result, these `ioctl`s form the substrate |
32 |
| -of the `sev` crate. Binaries that result from consumers of this crate are |
33 |
| -expected to run as a process with the necessary privileges to interact |
34 |
| -with the device nodes. |
35 |
| - |
36 |
| -[`firmware`]: ./firmware/index.html |
37 |
| -[`launch`]: ./launch/index.html |
| 6 | +# THIS REPOSITORY HAS MOVED |
38 | 7 |
|
39 |
| -License: Apache-2.0 |
| 8 | +https://github.com/virtee/sev |
0 commit comments