OpenSSH: 8.2 Release Notes

This release adds support for FIDO/U2F hardware authenticators to
OpenSSH. U2F/FIDO are open standards for inexpensive two-factor
authentication hardware that are widely used for website
authentication. In OpenSSH FIDO devices are supported by new public
key types “ecdsa-sk” and “ed25519-sk”, along with corresponding
certificate types.

FIDO/U2F OpenSSH keys consist of two parts: a “key handle” part stored
in the private key file on disk, and a per-device private key that is
unique to each FIDO/U2F token and that cannot be exported from the
token hardware. These are combined by the hardware at authentication
time to derive the real key that is used to sign authentication
challenges.

For tokens that are required to move between computers, it can be
cumbersome to have to move the private key file first. To avoid this
requirement, tokens implementing the newer FIDO2 standard support
“resident keys”, where it is possible to effectively retrieve the key
handle part of the key from the hardware.

Source: https://www.openssh.com/releasenotes.html#8.2

The Linux Kernel Now Seeing Patches For AMD SEV-ES “Encrypted State” Support – Phoronix

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.

Source: https://www.phoronix.com/scan.php?page=news_item&px=AMD-SEV-ES-Linux-2020-Patches

[RFC PATCH] mm: extend memfd with ability to create “secret” memory areas – Mike Rapoport

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):

Source: https://lore.kernel.org/lkml/20200130162340.GA14232@rapoport-lnx/

Keeping secrets in memfd areas [LWN.net]

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.

Source: https://lwn.net/SubscriberLink/812325/b642e849751b9068/