14 releases (stable)

4.0.0 Aug 8, 2024
3.2.0 Jul 10, 2024
3.1.1 Feb 29, 2024
2.0.2 Nov 4, 2023
0.1.0 Feb 2, 2021

#59 in Unix APIs

Download history 2019/week @ 2024-07-30 1910/week @ 2024-08-06 1976/week @ 2024-08-13 2451/week @ 2024-08-20 2513/week @ 2024-08-27 2343/week @ 2024-09-03 2823/week @ 2024-09-10 1744/week @ 2024-09-17 2418/week @ 2024-09-24 2761/week @ 2024-10-01 2294/week @ 2024-10-08 2241/week @ 2024-10-15 2432/week @ 2024-10-22 2827/week @ 2024-10-29 2458/week @ 2024-11-05 2574/week @ 2024-11-12

10,773 downloads per month
Used in 9 crates (8 directly)

Apache-2.0

400KB
9K SLoC

The sev crate provides an implementation of the AMD Secure Encrypted Virtualization (SEV) APIs and the SEV Secure Nested Paging Firmware (SNP) ABIs.

SEV APIs

The linux kernel exposes two technically distinct AMD SEV APIs:

  1. An API for managing the SEV platform itself
  2. An API for managing SEV-enabled KVM virtual machines

This crate implements both of those APIs and offers them to client. code through a flexible and type-safe high-level interface.

SNP ABIs

Like SEV, the linux kernel exposes another two different AMD SEV-SNP ABIs:

  1. An ABI for managing the SEV-SNP platform itself
  2. An ABI for managing SEV-SNP enabled KVM virtual machines

These new ABIs work only for SEV-SNP enabled hosts and guests.

This crate implements APIs for both SEV and SEV-SNP management.

SEV and SEV-SNP enablement

By default, both the SEV and SEV-SNP libraries are compiled. Because many modules provide support to both legacy SEV and SEV-SNP, they have been split into individual sub-modules sev.rs and snp.rs, isolating generation specific behavior. If desired, you may opt to exclude either of the sub-modules by disabling its feature in your project's Cargo.toml

For example, to include the SEV APIs only:
sev = { version = "1.2.1", default-features = false, features = ["sev"] }

To include the SEV-SNP APIs only:
sev = { version = "1.2.1", default-features = false, features = ["snp"] }

Platform Management

Refer to the firmware module for more information.

Guest Management

Refer to the launch module for more information.

Cryptographic Verification

To enable the cryptographic verification of certificate chains and attestation reports, either the openssl or crypto_nossl feature has to be enabled manually. With openssl, OpenSSL is used for the verification. With crypto_nossl, OpenSSL is not used for the verification and instead pure-Rust libraries (e.g., p384, rsa, etc.) are used. openssl and crypto_nossl are mutually exclusive, and enabling both at the same time leads to a compiler error.

Remarks

Note that the linux kernel provides access to these APIs through a set of ioctls that are meant to be called on device nodes (/dev/kvm and /dev/sev, to be specific). As a result, these ioctls form the substrate of the sev crate. Binaries that result from consumers of this crate are expected to run as a process with the necessary privileges to interact with the device nodes.

Using the C API

Projects in C can take advantage of the C API for the SEV launch ioctls. To install the C API, users can use cargo-c with the features they would like to produce and install a pkg-config file, a static library, a dynamic library, and a C header:

cargo cinstall --prefix=/usr --libdir=/usr/lib64

Dependencies

~1–13MB
~114K SLoC