Difference between revisions of "Bare-metal-trust"

Revision as of 06:30, 29 May 2015

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.

Work flow

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

From node enrollment to allocation and release, the various steps. Note BIOS re-flash and automatic enable TXT will not be available in this cycle

1. Manual work to prepare trusted boot (Outside of Ironic)

           (enable TXT, VT-x, VT-d, take ownership of the TPM)

2. Cleaning task to start trusted bot

           (Boot a customized image with OAT-Client using trusted boot)
           (Passing the OAT server URL for attestation)

3. Attestation (Outside of Ironic)

           Node sends its PCR values to the OAT-Server for attestation
           PCRs(0-7) BIOS/Option ROM related
           PCRs(17-22) kernel/Ramdisk related
           For bare metal trust we are chiefly concerned with PCRs(0-7)

4. Ironic polls the result from the OAT-Server as part of the cleaning task

           If trusted:
           Nodes are available and Jump to 6

5. Cleaning task to reflash Node 6. Deploying

           Boot guest image using trusted boot

7. Attestation by user (Outside of Ironic and optional) 8. Tenant releases node 9. Jump to 2