We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

Securing Secure Boot on Xen

Formale Metadaten

Titel
Securing Secure Boot on Xen
Serientitel
Anzahl der Teile
561
Autor
Lizenz
CC-Namensnennung 2.0 Belgien:
Sie dürfen das Werk bzw. den Inhalt zu jedem legalen Zweck nutzen, verändern und in unveränderter oder veränderter Form vervielfältigen, verbreiten und öffentlich zugänglich machen, sofern Sie den Namen des Autors/Rechteinhabers in der von ihm festgelegten Weise nennen.
Identifikatoren
Herausgeber
Erscheinungsjahr
Sprache

Inhaltliche Metadaten

Fachgebiet
Genre
Abstract
UEFI is a replacement for the BIOS. It supports Secure Boot which is signature verification of bootloaders and OS kernels which helps prevent attacks where malware injects itself into the bootloader or kernel so that it can be loaded during startup. Despite the poor reputation that Secure Boot has in the free software community (mostly due to non-technical reasons), this would be useful to have for VMs running on Xen. It is also required for features in guests such as Windows Credential Guard. This talk describes how Secure Boot support has been added to Xen. Xen has long had support for running guests booted with UEFI using a build of edk2/Tianocore built for VMs called OVMF. Systems that use UEFI boot have a small amount of NVRAM that stores variables critical for booting the system. Secure Boot is built upon the concepts of authenticated variables and a set of keys. Authenticated variables require updates to be signed by particular keys. These keys themselves are stored in authenticated variables. Verifying updates to authenticated variables needs to be performed in a way that cannot be tampered with by the guest which may have been infected by malware. There are a few ways of dealing with this. The talk will look at the approach taken by bare metal, KVM, and finally how we have implemented it for Xen. This is done by introducing a new component called varstored which runs outside of the context of the guest. It acts as an interface to the guest's NVRAM and verifies updates to it. Actual storage of the NVRAM is delegated to a number of backends to support different uses cases. For example, for a single host it could store the NVRAM in a simple file. For a pool of hosts it could store the NVRAM in database server accessible poolwide.