AMD SEV-ES allows for protecting the guest register state from the hypervisor. CPU register state is encrypted that cannot be accessed or modified by the system hypervisor. The intent of SEV-ES is to help fend off control-flow attacks by modifying the VM state, unauthorized reading of the virtual machine state, and other similar attacks. SEV-ES does allow for selectively sharing certain information to the hypervisor about certain switches where needed.
Extend memfd_create() system call with the ability to create memory areas
visible only in the context of the owning process and not mapped not only
to other processes but in the kernel page tables as well.
The user will create a file descriptor using the memfd_create system call.
The user than has to use ioctl() to define the desired protection mode for
the memory associated with that file descriptor and only when the mode is
set it is possible to mmap() the memory. For instance, the following
exapmple will create an uncached mapping (error handling is omitted):
The memfd subsystem wasn’t designed for address-space isolation; indeed, its initial purpose was as a sort of interprocess communication mechanism. It does, however, provide a way to create a memory region attached to a file descriptor with specific characteristics; a memfd can be “sealed”, for example, so that a recipient knows that it will not be changed. Rapoport decided that it would be a good foundation on which to build a “secret memory” feature.
This paper describes a network storage system, called
Venti, intended for archival data. In this system, a
unique hash of a block’s contents acts as the block
identifier for read and write operations. This approach
enforces a write-once policy, preventing accidental or
malicious destruction of data. In addition, duplicate
copies of a block can be coalesced, reducing the
consumption of storage and simplifying the
implementation of clients. Venti is a building block for
constructing a variety of storage applications such as
logical backup, physical backup, and snapshot file
We have built a prototype of the system and present
some preliminary performance results. The system uses
magnetic disks as the storage technology, resulting in
an access time for archival data that is comparable to
non-archival data. The feasibility of the write-once
model for storage is demonstrated using data from over
a decade’s use of two Plan 9 file systems.
This paper is a revision of Thompsons The Plan 9 File Server, and
describes the structure and the operation of the new 64-bit Plan 9 file
servers. Some specifics apply to the 32-bit Plan 9 file server Emelie,
which code is also the basis for the user-level file server kfs.
In 2004, Collyer created a 64-bit version of Thompsons 32-bit file
server, updating all file offsets, sizes and block numbers to 64 bits. In
addition, triple- and quadruple-indirect blocks were implemented. File
name components were extended from 27 to 55 bytes. This code is also
the basis for the user-level file server cwfs(4).
The security architecture of the Plan 9″ operating system has
recently been redesigned to address some technical shortcomings. This
redesign provided an opportunity also to make the system more convenient to use securely. Plan 9 has thus improved in two ways not usually
seen together: it has become more secure and easier to use.
The central component of the new architecture is a per-user selfcontained agent called factotum. Factotum securely holds a copy of
the users keys and negotiates authentication protocols, on behalf of the
user, with secure services around the network. Concentrating security
code in a single program offers several advantages including: ease of
update or repair to broken security software and protocols; the ability to
run secure services at a lower privilege level; uniform management of
keys for all services; and an opportunity to provide single sign on, even
to unchanged legacy applications. Factotum has an unusual architecture: it is implemented as a Plan 9 file server.
In a distributed system networks are of paramount importance. This
paper describes the implementation, design philosophy, and organization
of network support in Plan 9. Topics include network requirements for
distributed systems, our kernel implementation, network naming, user
interfaces, and performance. We also observe that much of this organization is relevant to current systems.