Jump to: navigation, search

Bare-metal-trust

Revision as of 05:48, 29 May 2015 by Tan Lin (talk | contribs)

Problem description

===================

While hypervisors and virtual machines are a common paradigm in the Cloud, heavy compute users seek Bare Metal (BM) to eliminate the performance overhead incurred by virtualization. But how can the cloud provider determine that a user released BM node is free of malware, after all a BM user has full access to the machine and could have introduced rootkits and other malware.

Proposed solution

===================

Our solution essentially mimics how one may download software and compute its SHA-256 hash and compare against its advertised SHA-256 hash to determine its legitimacy. It involves using Intel TXT, which is composed of hardware, software, and firmware. The hardware, attached to the platform, called the Trusted Platform Module (TPM)[5], provides the hardware root of trust. Firmware on the TPM is used to compute secure hashes and save the secure hashes to a set of registers called Platform Configuration Registers (PCRs), with different registers containing different measurements. Other components are Intel virtualization technology, signed code modules, and a trusted boot loader called TBOOT[1]. Essentially the BIOS, option ROM, and kernel/Ramdisk are all measured in the various PCRs. From a bare metal trust standpoint, we are interested in PCRs 0-7(BIOS, option ROM). The kernel/Ramdisk measurements would depend on the image the tenant seeks to launch on their bare metal instance. PCR value testing is provided by an Open Attestation service, OAT[2]. Additional details in references.

We integrate Ironic with Intel TXT to enable detection on boot of any changes in the BIOS, PCIe device firmware, and/or kernel/Ramdisk from expected values. The bare metal is trusted only when there is an exact match. On a legitimate update, for example BIOS firmware upgrade, it is necessary to update the whitelist to include the new expected measurements. For increased cloud security, it is good practice to maintain the whitelist, clearing out old values after all machines are upgraded/updated.

Result:

An OAT client using the customized image verifies the trust state and passes the value to Ironic. The related Horizon blueprint [12] addresses displaying the trust status of a bare metal node on boot. An administrator on introducing new hardware into the cloud can confirm whether they need to update the whitelist if on boot the machine fails attestation. This could happen for one of many reasons, such as new hardware distinct from existing machines in the data center/enterprise, BIOS upgrade, new PCIe device attachments etc.