https://wiki.openstack.org/w/api.php?action=feedcontributions&user=Tan+Lin&feedformat=atomOpenStack - User contributions [en]2024-03-28T18:33:04ZUser contributionsMediaWiki 1.28.2https://wiki.openstack.org/w/index.php?title=Ironic-local-boot-kernel-parameters-script&diff=125905Ironic-local-boot-kernel-parameters-script2016-05-26T06:12:31Z<p>Tan Lin: Created page with "This is an reference script to pass kernel parameters to ironic local boot instances by using configdrive. This only works with Ubuntu image and users should modify this scrip..."</p>
<hr />
<div>This is an reference script to pass kernel parameters to ironic local boot instances by using configdrive.<br />
This only works with Ubuntu image and users should modify this script to fit their use case:<br />
<br />
#!/usr/bin/env python<br />
import os<br />
<br />
# Default grub2 config file in Ubuntu<br />
grub_file = '/etc/default/grub'<br />
# Add parameters here to pass to instance.<br />
kernel_parameters = ['quiet', 'splash']<br />
grub_cmd = 'GRUB_CMDLINE_LINUX'<br />
old_grub_file = grub_file+'~'<br />
os.rename(grub_file, old_grub_file)<br />
cmdline_existed = False<br />
with open(grub_file, 'w') as writer, \<br />
open(old_grub_file, 'r') as reader:<br />
for line in reader:<br />
key = line.split('=')[0]<br />
if key == grub_cmd:<br />
#If there is already some value:<br />
if line.strip()[-1] == '"':<br />
line = line.strip()[:-1] + ' ' + ' '.join(kernel_parameters) + '"'<br />
cmdline_existed = True<br />
writer.write(line)<br />
if not cmdline_existed:<br />
line = grub_cmd + '=' + '"' + ' '.join(kernel_parameters) + '"'<br />
writer.write(line)<br />
<br />
os.remove(old_grub_file)<br />
os.system('update-grub')<br />
os.system('reboot')</div>Tan Linhttps://wiki.openstack.org/w/index.php?title=Ironic-boot-kernel-parameters&diff=125835Ironic-boot-kernel-parameters2016-05-25T09:13:38Z<p>Tan Lin: </p>
<hr />
<div>This is a reference script to passing kernel paramters to ironic localboot instance using configdrive.<br />
This only works with ubuntu image, so users should modify this script by their own use case:<br />
<br />
#!/usr/bin/env python<br />
import os<br />
<br />
# Default grub2 config file in Ubuntu<br />
grub_file = '/etc/default/grub'<br />
# Add parameters here to pass to instance.<br />
kernel_parameters = ['quiet', 'splash']<br />
grub_cmd = 'GRUB_CMDLINE_LINUX'<br />
old_grub_file = grub_file+'~'<br />
os.rename(grub_file, old_grub_file)<br />
cmdline_existed = False<br />
with open(grub_file, 'w') as writer, \<br />
open(old_grub_file, 'r') as reader:<br />
for line in reader:<br />
key = line.split('=')[0]<br />
if key == grub_cmd:<br />
#If there is already some value:<br />
if line.strip()[-1] == '"':<br />
line = line.strip()[:-1] + ' ' + ' '.join(kernel_parameters) + '"'<br />
cmdline_existed = True<br />
writer.write(line)<br />
if not cmdline_existed:<br />
line = grub_cmd + '=' + '"' + ' '.join(kernel_parameters) + '"'<br />
writer.write(line)<br />
<br />
os.remove(old_grub_file)<br />
os.system('update-grub')<br />
os.system('reboot')</div>Tan Linhttps://wiki.openstack.org/w/index.php?title=Ironic-boot-kernel-parameters&diff=124611Ironic-boot-kernel-parameters2016-05-03T09:26:50Z<p>Tan Lin: Created page with "#!/usr/bin/env python import os grub_file = '/etc/default/grub' kernel_parameters = ['quiet', 'splash'] grub_cmd = 'GRUB_CMDLINE_LINUX' old_grub_file = grub_file+'~' os.rena..."</p>
<hr />
<div>#!/usr/bin/env python<br />
import os<br />
<br />
grub_file = '/etc/default/grub'<br />
kernel_parameters = ['quiet', 'splash']<br />
grub_cmd = 'GRUB_CMDLINE_LINUX'<br />
old_grub_file = grub_file+'~'<br />
os.rename(grub_file, old_grub_file)<br />
cmdline_existed = False<br />
with open(grub_file, 'w') as writer, \<br />
open(old_grub_file, 'r') as reader:<br />
for line in reader:<br />
key = line.split('=')[0]<br />
if key == grub_cmd:<br />
#If there is already some value:<br />
if line.strip()[-1] == '"':<br />
line = line.strip()[:-1] + ' ' + ' '.join(kernel_parameters) + '"'<br />
cmdline_existed = True<br />
writer.write(line)<br />
if not cmdline_existed:<br />
line = grub_cmd + '=' + '"' + ' '.join(kernel_parameters) + '"'<br />
writer.write(line)<br />
<br />
os.remove(old_grub_file)<br />
os.system('update-grub')<br />
os.system('reboot')</div>Tan Linhttps://wiki.openstack.org/w/index.php?title=Meetings/Ironic&diff=102385Meetings/Ironic2016-01-28T13:07:29Z<p>Tan Lin: /* Agenda for next meeting */</p>
<hr />
<div>= Weekly Ironic Project Team Meeting =<br />
<br />
If you're interested in bare metal deployments within OpenStack, please join our weekly discussion about the [[Ironic|Ironic project]]! The one-hour weekly meetings start at 1700 UTC on Mondays, are held in the <code><nowiki>#openstack-meeting-3</nowiki></code> room on <code><nowiki>irc.freenode.net</nowiki></code>, and are chaired by Jim Rollenhagen (jroll), Devananda van der Veen (devananda) or Chris Krelle (NobodyCam).<br />
<br />
NOTE: <span style="color:green">Meeting time is UTC based and may need to be adjusted based on local time zone changes, eg. as a result of daylight savings, which changes on different days in different countries.</span><br><br />
<br />
* [http://eavesdrop.openstack.org/calendars/ironic-bare-metal-team-meeting.ics ICS (Calendar) file] for the meeting. You can add this to your calendar.<br />
* [http://eavesdrop.openstack.org/#Ironic_%28Bare_Metal%29_Team_Meeting Eavesdrop meeting page]<br />
<br />
<br />
Anyone is welcome to add topics to the agenda. However, topics should be posted '''at least two (2) days before the meeting''' to give folks time to get context, and should include the IRC handle of the proposer and a link to further information. This gives everyone time to review any material ahead of time so we can use the meeting time for actual discussion. Requests to have a patch reviewed should not be a topic and instead should be covered during the Open Discussion portion of the meeting.<br />
* Example topic: (devananda) Let's talk about zebras. Reference: http://en.wikipedia.org/wiki/Zebra<br />
<br />
== Next Meeting ==<br />
The next meeting will be on February 01, 2016 at 1700 UTC (http://www.timeanddate.com/worldclock/fixedtime.html?iso=20160201T1700).<br />
<br />
== Agenda for next meeting ==<br />
* Announcements / Reminders<br />
* Review [https://etherpad.openstack.org/p/IronicWhiteBoard subteam status reports] (capped at ten minutes)<br />
* Stuck specs (Specs that are stuck on contentious items. This is NOT for specs that are stuck because they aren't getting reviews.)<br />
* Discussion (Requests to have your patch reviewed should not be a 'Discussion' topic. If desired, please discuss during 'Open Discussion')<br />
(lintan) should we support a new feature to accept header 'X-Openstack-Request-ID' as request_id?<br />
https://etherpad.openstack.org/p/Ironic-openstack-request-id<br />
<br />
== Previous meetings ==<br />
<br />
[http://eavesdrop.openstack.org/meetings/ironic/ Logs from previous meetings can be found here.]<br />
<br />
== Related meetings ==<br />
<br />
* [https://wiki.openstack.org/wiki/Meetings/Ironic-neutron Ironic/Neutron integration meets weekly on Monday at 1600 UTC.]<br />
* [https://wiki.openstack.org/wiki/Meetings/Ironic-QA Ironic-QA meets weekly on Wednesdays at 1700 UTC.]</div>Tan Linhttps://wiki.openstack.org/w/index.php?title=Meetings/Ironic&diff=102268Meetings/Ironic2016-01-27T10:04:19Z<p>Tan Lin: /* Agenda for next meeting */</p>
<hr />
<div>= Weekly Ironic Project Team Meeting =<br />
<br />
If you're interested in bare metal deployments within OpenStack, please join our weekly discussion about the [[Ironic|Ironic project]]! The one-hour weekly meetings start at 1700 UTC on Mondays, are held in the <code><nowiki>#openstack-meeting-3</nowiki></code> room on <code><nowiki>irc.freenode.net</nowiki></code>, and are chaired by Jim Rollenhagen (jroll), Devananda van der Veen (devananda) or Chris Krelle (NobodyCam).<br />
<br />
NOTE: <span style="color:green">Meeting time is UTC based and may need to be adjusted based on local time zone changes, eg. as a result of daylight savings, which changes on different days in different countries.</span><br><br />
<br />
* [http://eavesdrop.openstack.org/calendars/ironic-bare-metal-team-meeting.ics ICS (Calendar) file] for the meeting. You can add this to your calendar.<br />
* [http://eavesdrop.openstack.org/#Ironic_%28Bare_Metal%29_Team_Meeting Eavesdrop meeting page]<br />
<br />
<br />
Anyone is welcome to add topics to the agenda. However, topics should be posted '''at least two (2) days before the meeting''' to give folks time to get context, and should include the IRC handle of the proposer and a link to further information. This gives everyone time to review any material ahead of time so we can use the meeting time for actual discussion. Requests to have a patch reviewed should not be a topic and instead should be covered during the Open Discussion portion of the meeting.<br />
* Example topic: (devananda) Let's talk about zebras. Reference: http://en.wikipedia.org/wiki/Zebra<br />
<br />
== Next Meeting ==<br />
The next meeting will be on February 01, 2016 at 1700 UTC (http://www.timeanddate.com/worldclock/fixedtime.html?iso=20160201T1700).<br />
<br />
== Agenda for next meeting ==<br />
* Announcements / Reminders<br />
* Review [https://etherpad.openstack.org/p/IronicWhiteBoard subteam status reports] (capped at ten minutes)<br />
* Stuck specs (Specs that are stuck on contentious items. This is NOT for specs that are stuck because they aren't getting reviews.)<br />
* Discussion (Requests to have your patch reviewed should not be a 'Discussion' topic. If desired, please discuss during 'Open Discussion')<br />
(lintan) should we support a new feature to accept header 'X-Openstack-Request-ID' as request_id?<br />
https://review.openstack.org/#/c/238008/<br />
We have a cross spec to return 'X-Openstack-Request-Id': https://blueprints.launchpad.net/nova/+spec/cross-service-request-id<br />
But I read the spec and get double confirm from other projects: <br />
The spec is not asking us to accept an external passed request-id as the project’s own request-id, it only needs to return request-id.<br />
http://osdir.com/ml/openstack-dev/2016-01/msg01745.html<br />
So I would like to discuss two points: <br />
1. Should we accept the header as request_id or just generate a request_id and append it to response headers?<br />
2. Since Neutron and Keystone didn't support accept external request_id, this is not so useful from the perspective of Ironic, do we need the feature at all?<br />
* Open Discussion<br />
<br />
== Previous meetings ==<br />
<br />
[http://eavesdrop.openstack.org/meetings/ironic/ Logs from previous meetings can be found here.]<br />
<br />
== Related meetings ==<br />
<br />
* [https://wiki.openstack.org/wiki/Meetings/Ironic-neutron Ironic/Neutron integration meets weekly on Monday at 1600 UTC.]<br />
* [https://wiki.openstack.org/wiki/Meetings/Ironic-QA Ironic-QA meets weekly on Wednesdays at 1700 UTC.]</div>Tan Linhttps://wiki.openstack.org/w/index.php?title=Meetings/Ironic&diff=102265Meetings/Ironic2016-01-27T09:57:51Z<p>Tan Lin: /* Agenda for next meeting */</p>
<hr />
<div>= Weekly Ironic Project Team Meeting =<br />
<br />
If you're interested in bare metal deployments within OpenStack, please join our weekly discussion about the [[Ironic|Ironic project]]! The one-hour weekly meetings start at 1700 UTC on Mondays, are held in the <code><nowiki>#openstack-meeting-3</nowiki></code> room on <code><nowiki>irc.freenode.net</nowiki></code>, and are chaired by Jim Rollenhagen (jroll), Devananda van der Veen (devananda) or Chris Krelle (NobodyCam).<br />
<br />
NOTE: <span style="color:green">Meeting time is UTC based and may need to be adjusted based on local time zone changes, eg. as a result of daylight savings, which changes on different days in different countries.</span><br><br />
<br />
* [http://eavesdrop.openstack.org/calendars/ironic-bare-metal-team-meeting.ics ICS (Calendar) file] for the meeting. You can add this to your calendar.<br />
* [http://eavesdrop.openstack.org/#Ironic_%28Bare_Metal%29_Team_Meeting Eavesdrop meeting page]<br />
<br />
<br />
Anyone is welcome to add topics to the agenda. However, topics should be posted '''at least two (2) days before the meeting''' to give folks time to get context, and should include the IRC handle of the proposer and a link to further information. This gives everyone time to review any material ahead of time so we can use the meeting time for actual discussion. Requests to have a patch reviewed should not be a topic and instead should be covered during the Open Discussion portion of the meeting.<br />
* Example topic: (devananda) Let's talk about zebras. Reference: http://en.wikipedia.org/wiki/Zebra<br />
<br />
== Next Meeting ==<br />
The next meeting will be on February 01, 2016 at 1700 UTC (http://www.timeanddate.com/worldclock/fixedtime.html?iso=20160201T1700).<br />
<br />
== Agenda for next meeting ==<br />
* Announcements / Reminders<br />
* Review [https://etherpad.openstack.org/p/IronicWhiteBoard subteam status reports] (capped at ten minutes)<br />
* Stuck specs (Specs that are stuck on contentious items. This is NOT for specs that are stuck because they aren't getting reviews.)<br />
* Discussion (Requests to have your patch reviewed should not be a 'Discussion' topic. If desired, please discuss during 'Open Discussion')<br />
(lintan) should we support a new feature to accept header 'X-Openstack-Request-ID' as request_id?<br />
We have a cross spec to return 'X-Openstack-Request-Id': https://blueprints.launchpad.net/nova/+spec/cross-service-request-id<br />
But I get confirm from other projects: The spec is not asking us to accept an external passed request-id as the project’s own request-id, it only needs to return request-id:<br />
http://osdir.com/ml/openstack-dev/2016-01/msg01745.html<br />
So I would like to discuss two points: <br />
1. should we accept the header as request_id or just automatically generate a request_id and append it to headers.<br />
2. Since Neutron and Keystone didn't support accept external request_id, this is not useful from the perspective of Ironic, do we need the feature at all?<br />
* Open Discussion<br />
<br />
== Previous meetings ==<br />
<br />
[http://eavesdrop.openstack.org/meetings/ironic/ Logs from previous meetings can be found here.]<br />
<br />
== Related meetings ==<br />
<br />
* [https://wiki.openstack.org/wiki/Meetings/Ironic-neutron Ironic/Neutron integration meets weekly on Monday at 1600 UTC.]<br />
* [https://wiki.openstack.org/wiki/Meetings/Ironic-QA Ironic-QA meets weekly on Wednesdays at 1700 UTC.]</div>Tan Linhttps://wiki.openstack.org/w/index.php?title=Bare-metal-trust&diff=88055Bare-metal-trust2015-08-14T01:47:42Z<p>Tan Lin: /* Typical use cases of bare metal trust */</p>
<hr />
<div>==Problem description==<br />
While hypervisors and virtual machines are a common paradigm in the Cloud, heavy compute users seek Bare Metal (BM) to eliminate the performance overhead <br />
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.<br />
<br />
==Proposed solution==<br />
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<br />
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)[3], 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<br />
called TBOOT[1].<br />
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<br />
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<br />
testing is provided by an Open Attestation service, OAT[2]. Additional details in references.<br />
<br />
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.<br />
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<br />
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.<br />
<br />
'''Result:'''<br />
<br />
An OAT client using the customized image verifies the trust state and passes the value to Ironic. A related Horizon blueprint addresses displaying<br />
the trust status of a bare metal node on boot. <br />
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.<br />
<br />
==Typical use cases of bare metal trust==<br />
Here is an use case for bare metal trust which will measure each node when it release<br />
<br />
1. Manual work to prepare trusted boot<br />
(enable TXT, VT-x, VT-d, take ownership of the TPM)<br />
2. Enable trusted boot for Ironic<br />
Create a customized user image with ``oat-client`` installed<br />
Enroll a node and update its capability value with `trusted_boot`=`true`<br />
Create a special flavor with 'capabilities:trusted_boot'=true<br />
Prepare `tboot` and mboot.c32 and put them into tftp_root<br />
3. Set up an OAT-Server<br />
https://github.com/OpenAttestation/OpenAttestation/wiki/<br />
4. Deploy on node and using trusted boot to measure node<br />
(Boot a customized user image with OAT-Client using trusted boot)<br />
(Passing the OAT server URL for attestation)<br />
5. Attestation<br />
(Polls the result from the OAT-Server)<br />
If trusted:<br />
Nodes are available and continue<br />
6. Re-Deploy<br />
Boot the tenant user image<br />
7. Tenant releases node<br />
Jump to 4<br />
<br />
==Trust Script Example==<br />
Node has to register itself into OAT-Server and wait for attestation, this can be done via boot instance with user-data, here is a sample about the user-data:<br />
<br />
#!/bin/bash -v<br />
modprobe tpm_tis<br />
modprobe tpm<br />
#OAT-Sever's info<br />
OAT_SERVER_IP=10.239.48.127<br />
OAT_SERVER_USER=admin<br />
OAT_SERVER_PASSWD=p2<br />
<br />
#Node's IP<br />
DEV=eth1<br />
dhclient $DEV<br />
OAT_CLIENT_IP=$(ip addr show dev $DEV | grep ' inet '| awk '{print $2}'|cut -c -12)<br />
OAT_CLIENT_HOST=$OAT_CLIENT_IP<br />
<br />
#Node's info<br />
bios=NewMLE1<br />
bios_ver=v123<br />
oem_manu=OEM1<br />
vmm=NewMLE2<br />
vmm_ver=v123<br />
os=OS1<br />
os_ver=v1<br />
<br />
#Init OAT-Client<br />
iptables -A INPUT -p tcp --dport 8181 -j ACCEPT<br />
iptables -A INPUT -p tcp --dport 8080 -j ACCEPT<br />
iptables -A INPUT -p tcp --dport 9999 -j ACCEPT<br />
iptables -A INPUT -p tcp --dport 9998 -j ACCEPT<br />
/usr/bin/tagent setup <<EOF<br />
$OAT_SERVER_IP \<br />
<br />
$OAT_SERVER_USER<br />
$OAT_SERVER_PASSWD<br />
EOF<br />
<br />
#register a new host<br />
oat_cert -h $OAT_SERVER_IP<br />
oat_host -a -h $OAT_SERVER_IP "<br />
{\"HostName\":\"$OAT_CLIENT_HOST\",\"IPAddress\":\"$OAT_CLIENT_IP\",\"Port\":\"9999\",\"BIOS_Name\":\"$bios\",\"BIOS_Version\":\"$bios_ver\",\"BIOS_Oem\":\"$oem_manu\",\"VMM_Name\":\"$vmm\",\"VMM_Version\":\"$vmm_ver\",\"VMM_OSName\":\"$os\",\"VMM_OSVersion\":\"$os_ver\",\"Email\":\"\",\"AddOn_Connection_String\":\"\",\"Description\":\"\"}"<br />
<br />
==Manual verify result==<br />
User can install and use oat-command tool to query the trust state of the node<br />
oat_cert -h $OAT_SERVER_IP<br />
oat_pollhosts -h $OAT_SERVER_IP '{"hosts":["$OAT_CLIENT_IP"]}'<br />
<br />
==Limitations and Future Work==<br />
1) Previously, a clean task to rebuild the node with trusted boot was proposed. But it was much<br />
more complicated in Ironic's current framework after investigation. Because the node has to leave clean stage if it wants<br />
to rebuild. A tool which is on the top of Ironic is a better solution so far. It can log the trust<br />
state and trigger Ironic for further steps.<br />
<br />
2) Hot Add/Remove of PCIe devices are not supported. A machine reboot is<br />
necessary to obtain fresh measurements and re-attestation.<br />
<br />
3) Blue Pill<br />
When the hardware virtualization support is enabled without a hypervisor<br />
running, the machine is open to launch a Blue Pill style attack. Unfortunately<br />
OEM vendors do not provide the capability to disable Intel TXT or its<br />
equivalents and those that tried to support the same insisted on establishing<br />
physical presence. The reasoning here is the dynamic control feature itself<br />
could pose a vulnerability. Our goal is unaffected by the Blue Pill aspect<br />
because we are concerned strictly with establishing that a machine prior to<br />
hand-off to a tenant is clean, free of rootkits and malware. Should the tenant<br />
seek to install a rootkit, that is in their purview. Once the machine is<br />
released back to the cloud, our workflow will detect and erase the same.<br />
<br />
This said, no claims of trust or re-attestation of a bare metal machine are<br />
possible post boot time. In the Horizon dashboard re-attest action<br />
will not be provided. Node boot time and trust status at boot time will<br />
be displayed.<br />
<br />
==References==<br />
1. http://sourceforge.net/projects/tboot/<br />
<br />
2. https://github.com/OpenAttestation/OpenAttestation<br />
<br />
3. http://en.wikipedia.org/wiki/Trusted_Platform_Module<br />
<br />
4. http://en.wikipedia.org/wiki/Trusted_Execution_Technology<br />
<br />
5. http://docs.openstack.org/admin-guide-cloud/content/trusted-compute-pools.html</div>Tan Linhttps://wiki.openstack.org/w/index.php?title=Bare-metal-trust&diff=87953Bare-metal-trust2015-08-13T06:57:51Z<p>Tan Lin: /* A typical use case of bare metal trust */</p>
<hr />
<div>==Problem description==<br />
While hypervisors and virtual machines are a common paradigm in the Cloud, heavy compute users seek Bare Metal (BM) to eliminate the performance overhead <br />
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.<br />
<br />
==Proposed solution==<br />
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<br />
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)[3], 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<br />
called TBOOT[1].<br />
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<br />
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<br />
testing is provided by an Open Attestation service, OAT[2]. Additional details in references.<br />
<br />
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.<br />
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<br />
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.<br />
<br />
'''Result:'''<br />
<br />
An OAT client using the customized image verifies the trust state and passes the value to Ironic. A related Horizon blueprint addresses displaying<br />
the trust status of a bare metal node on boot. <br />
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.<br />
<br />
==Typical use cases of bare metal trust==<br />
Here is an use case for bare metal trust which will measure each node when it release<br />
<br />
1. Manual work to prepare trusted boot<br />
(enable TXT, VT-x, VT-d, take ownership of the TPM)<br />
2. Enable trusted boot for Ironic<br />
Enroll a node and update its capability value with `trusted_boot`=`true`<br />
Create a special flavor with 'capabilities:trusted_boot'=true<br />
Prepare `tboot` and mboot.c32 and put them into tftp_root<br />
3. Set up an OAT-Server<br />
https://github.com/OpenAttestation/OpenAttestation/wiki/<br />
4. Deploy on node and using trusted boot to measure node<br />
(Boot a customized user image with OAT-Client using trusted boot)<br />
(Passing the OAT server URL for attestation)<br />
5. Attestation<br />
(Polls the result from the OAT-Server)<br />
If trusted:<br />
Nodes are available and continue<br />
6. Re-Deploy<br />
Boot the tenant user image<br />
7. Tenant releases node<br />
Jump to 4<br />
<br />
==Trust Script Example==<br />
Node has to register itself into OAT-Server and wait for attestation, this can be done via boot instance with user-data, here is a sample about the user-data:<br />
<br />
#!/bin/bash -v<br />
modprobe tpm_tis<br />
modprobe tpm<br />
#OAT-Sever's info<br />
OAT_SERVER_IP=10.239.48.127<br />
OAT_SERVER_USER=admin<br />
OAT_SERVER_PASSWD=p2<br />
<br />
#Node's IP<br />
DEV=eth1<br />
dhclient $DEV<br />
OAT_CLIENT_IP=$(ip addr show dev $DEV | grep ' inet '| awk '{print $2}'|cut -c -12)<br />
OAT_CLIENT_HOST=$OAT_CLIENT_IP<br />
<br />
#Node's info<br />
bios=NewMLE1<br />
bios_ver=v123<br />
oem_manu=OEM1<br />
vmm=NewMLE2<br />
vmm_ver=v123<br />
os=OS1<br />
os_ver=v1<br />
<br />
#Init OAT-Client<br />
iptables -A INPUT -p tcp --dport 8181 -j ACCEPT<br />
iptables -A INPUT -p tcp --dport 8080 -j ACCEPT<br />
iptables -A INPUT -p tcp --dport 9999 -j ACCEPT<br />
iptables -A INPUT -p tcp --dport 9998 -j ACCEPT<br />
/usr/bin/tagent setup <<EOF<br />
$OAT_SERVER_IP \<br />
<br />
$OAT_SERVER_USER<br />
$OAT_SERVER_PASSWD<br />
EOF<br />
<br />
#register a new host<br />
oat_cert -h $OAT_SERVER_IP<br />
oat_host -a -h $OAT_SERVER_IP "<br />
{\"HostName\":\"$OAT_CLIENT_HOST\",\"IPAddress\":\"$OAT_CLIENT_IP\",\"Port\":\"9999\",\"BIOS_Name\":\"$bios\",\"BIOS_Version\":\"$bios_ver\",\"BIOS_Oem\":\"$oem_manu\",\"VMM_Name\":\"$vmm\",\"VMM_Version\":\"$vmm_ver\",\"VMM_OSName\":\"$os\",\"VMM_OSVersion\":\"$os_ver\",\"Email\":\"\",\"AddOn_Connection_String\":\"\",\"Description\":\"\"}"<br />
<br />
==Manual verify result==<br />
User can install and use oat-command tool to query the trust state of the node<br />
oat_cert -h $OAT_SERVER_IP<br />
oat_pollhosts -h $OAT_SERVER_IP '{"hosts":["$OAT_CLIENT_IP"]}'<br />
<br />
==Limitations and Future Work==<br />
1) Previously, a clean task to rebuild the node with trusted boot was proposed. But it was much<br />
more complicated in Ironic's current framework after investigation. Because the node has to leave clean stage if it wants<br />
to rebuild. A tool which is on the top of Ironic is a better solution so far. It can log the trust<br />
state and trigger Ironic for further steps.<br />
<br />
2) Hot Add/Remove of PCIe devices are not supported. A machine reboot is<br />
necessary to obtain fresh measurements and re-attestation.<br />
<br />
3) Blue Pill<br />
When the hardware virtualization support is enabled without a hypervisor<br />
running, the machine is open to launch a Blue Pill style attack. Unfortunately<br />
OEM vendors do not provide the capability to disable Intel TXT or its<br />
equivalents and those that tried to support the same insisted on establishing<br />
physical presence. The reasoning here is the dynamic control feature itself<br />
could pose a vulnerability. Our goal is unaffected by the Blue Pill aspect<br />
because we are concerned strictly with establishing that a machine prior to<br />
hand-off to a tenant is clean, free of rootkits and malware. Should the tenant<br />
seek to install a rootkit, that is in their purview. Once the machine is<br />
released back to the cloud, our workflow will detect and erase the same.<br />
<br />
This said, no claims of trust or re-attestation of a bare metal machine are<br />
possible post boot time. In the Horizon dashboard re-attest action<br />
will not be provided. Node boot time and trust status at boot time will<br />
be displayed.<br />
<br />
==References==<br />
1. http://sourceforge.net/projects/tboot/<br />
<br />
2. https://github.com/OpenAttestation/OpenAttestation<br />
<br />
3. http://en.wikipedia.org/wiki/Trusted_Platform_Module<br />
<br />
4. http://en.wikipedia.org/wiki/Trusted_Execution_Technology<br />
<br />
5. http://docs.openstack.org/admin-guide-cloud/content/trusted-compute-pools.html</div>Tan Linhttps://wiki.openstack.org/w/index.php?title=Bare-metal-trust&diff=87948Bare-metal-trust2015-08-13T02:55:24Z<p>Tan Lin: /* A typical use case of bare metal trust */</p>
<hr />
<div>==Problem description==<br />
While hypervisors and virtual machines are a common paradigm in the Cloud, heavy compute users seek Bare Metal (BM) to eliminate the performance overhead <br />
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.<br />
<br />
==Proposed solution==<br />
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<br />
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)[3], 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<br />
called TBOOT[1].<br />
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<br />
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<br />
testing is provided by an Open Attestation service, OAT[2]. Additional details in references.<br />
<br />
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.<br />
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<br />
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.<br />
<br />
'''Result:'''<br />
<br />
An OAT client using the customized image verifies the trust state and passes the value to Ironic. A related Horizon blueprint addresses displaying<br />
the trust status of a bare metal node on boot. <br />
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.<br />
<br />
==A typical use case of bare metal trust==<br />
Here is an use case for bare metal trust which will measure each node when it release<br />
<br />
1. Manual work to prepare trusted boot<br />
(enable TXT, VT-x, VT-d, take ownership of the TPM)<br />
2. Set up an OAT-Server<br />
https://github.com/OpenAttestation/OpenAttestation/wiki/<br />
3. Enable trusted boot for Ironic<br />
http://docs.openstack.org/developer/ironic/deploy/install-guide.html#Trusted-boot-with-partition-image<br />
4. Deploy on node and using trusted boot to measure node<br />
(Boot a customized user image with OAT-Client using trusted boot)<br />
(Passing the OAT server URL for attestation)<br />
5. Attestation<br />
(Polls the result from the OAT-Server)<br />
If trusted:<br />
Nodes are available and continue<br />
6. Re-Deploy<br />
Boot the tenant user image<br />
7. Tenant releases node<br />
Jump to 4<br />
<br />
==Trust Script Example==<br />
Node has to register itself into OAT-Server and wait for attestation, this can be done via boot instance with user-data, here is a sample about the user-data:<br />
<br />
#!/bin/bash -v<br />
modprobe tpm_tis<br />
modprobe tpm<br />
#OAT-Sever's info<br />
OAT_SERVER_IP=10.239.48.127<br />
OAT_SERVER_USER=admin<br />
OAT_SERVER_PASSWD=p2<br />
<br />
#Node's IP<br />
DEV=eth1<br />
dhclient $DEV<br />
OAT_CLIENT_IP=$(ip addr show dev $DEV | grep ' inet '| awk '{print $2}'|cut -c -12)<br />
OAT_CLIENT_HOST=$OAT_CLIENT_IP<br />
<br />
#Node's info<br />
bios=NewMLE1<br />
bios_ver=v123<br />
oem_manu=OEM1<br />
vmm=NewMLE2<br />
vmm_ver=v123<br />
os=OS1<br />
os_ver=v1<br />
<br />
#Init OAT-Client<br />
iptables -A INPUT -p tcp --dport 8181 -j ACCEPT<br />
iptables -A INPUT -p tcp --dport 8080 -j ACCEPT<br />
iptables -A INPUT -p tcp --dport 9999 -j ACCEPT<br />
iptables -A INPUT -p tcp --dport 9998 -j ACCEPT<br />
/usr/bin/tagent setup <<EOF<br />
$OAT_SERVER_IP \<br />
<br />
$OAT_SERVER_USER<br />
$OAT_SERVER_PASSWD<br />
EOF<br />
<br />
#register a new host<br />
oat_cert -h $OAT_SERVER_IP<br />
oat_host -a -h $OAT_SERVER_IP "<br />
{\"HostName\":\"$OAT_CLIENT_HOST\",\"IPAddress\":\"$OAT_CLIENT_IP\",\"Port\":\"9999\",\"BIOS_Name\":\"$bios\",\"BIOS_Version\":\"$bios_ver\",\"BIOS_Oem\":\"$oem_manu\",\"VMM_Name\":\"$vmm\",\"VMM_Version\":\"$vmm_ver\",\"VMM_OSName\":\"$os\",\"VMM_OSVersion\":\"$os_ver\",\"Email\":\"\",\"AddOn_Connection_String\":\"\",\"Description\":\"\"}"<br />
<br />
==Manual verify result==<br />
User can install and use oat-command tool to query the trust state of the node<br />
oat_cert -h $OAT_SERVER_IP<br />
oat_pollhosts -h $OAT_SERVER_IP '{"hosts":["$OAT_CLIENT_IP"]}'<br />
<br />
==Limitations and Future Work==<br />
1) Previously, a clean task to rebuild the node with trusted boot was proposed. But it was much<br />
more complicated in Ironic's current framework after investigation. Because the node has to leave clean stage if it wants<br />
to rebuild. A tool which is on the top of Ironic is a better solution so far. It can log the trust<br />
state and trigger Ironic for further steps.<br />
<br />
2) Hot Add/Remove of PCIe devices are not supported. A machine reboot is<br />
necessary to obtain fresh measurements and re-attestation.<br />
<br />
3) Blue Pill<br />
When the hardware virtualization support is enabled without a hypervisor<br />
running, the machine is open to launch a Blue Pill style attack. Unfortunately<br />
OEM vendors do not provide the capability to disable Intel TXT or its<br />
equivalents and those that tried to support the same insisted on establishing<br />
physical presence. The reasoning here is the dynamic control feature itself<br />
could pose a vulnerability. Our goal is unaffected by the Blue Pill aspect<br />
because we are concerned strictly with establishing that a machine prior to<br />
hand-off to a tenant is clean, free of rootkits and malware. Should the tenant<br />
seek to install a rootkit, that is in their purview. Once the machine is<br />
released back to the cloud, our workflow will detect and erase the same.<br />
<br />
This said, no claims of trust or re-attestation of a bare metal machine are<br />
possible post boot time. In the Horizon dashboard re-attest action<br />
will not be provided. Node boot time and trust status at boot time will<br />
be displayed.<br />
<br />
==References==<br />
1. http://sourceforge.net/projects/tboot/<br />
<br />
2. https://github.com/OpenAttestation/OpenAttestation<br />
<br />
3. http://en.wikipedia.org/wiki/Trusted_Platform_Module<br />
<br />
4. http://en.wikipedia.org/wiki/Trusted_Execution_Technology<br />
<br />
5. http://docs.openstack.org/admin-guide-cloud/content/trusted-compute-pools.html</div>Tan Linhttps://wiki.openstack.org/w/index.php?title=Bare-metal-trust&diff=87947Bare-metal-trust2015-08-13T02:54:48Z<p>Tan Lin: /* A typical use case of bare metal trust */</p>
<hr />
<div>==Problem description==<br />
While hypervisors and virtual machines are a common paradigm in the Cloud, heavy compute users seek Bare Metal (BM) to eliminate the performance overhead <br />
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.<br />
<br />
==Proposed solution==<br />
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<br />
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)[3], 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<br />
called TBOOT[1].<br />
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<br />
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<br />
testing is provided by an Open Attestation service, OAT[2]. Additional details in references.<br />
<br />
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.<br />
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<br />
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.<br />
<br />
'''Result:'''<br />
<br />
An OAT client using the customized image verifies the trust state and passes the value to Ironic. A related Horizon blueprint addresses displaying<br />
the trust status of a bare metal node on boot. <br />
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.<br />
<br />
==A typical use case of bare metal trust==<br />
Here is an use case for bare metal trust which will measure each node when it release<br />
<br />
1. Manual work to prepare trusted boot<br />
(enable TXT, VT-x, VT-d, take ownership of the TPM)<br />
2. Set up an OAT-Server<br />
https://github.com/OpenAttestation/OpenAttestation/wiki/<br />
3. Enable trusted boot for Ironic<br />
http://docs.openstack.org/developer/ironic/deploy/install-guide.html#Trusted-boot-with-partition-image<br />
4. Deploy on node and using trusted boot to measure node<br />
(Boot a customized user image with OAT-Client using trusted boot)<br />
(Passing the OAT server URL for attestation)<br />
5. Attestation<br />
(Polls the result from the OAT-Server)<br />
If trusted:<br />
Nodes are available and continue<br />
6. Re-Deploy<br />
Boot guest's user image<br />
7. Tenant releases node<br />
Jump to 4<br />
<br />
==Trust Script Example==<br />
Node has to register itself into OAT-Server and wait for attestation, this can be done via boot instance with user-data, here is a sample about the user-data:<br />
<br />
#!/bin/bash -v<br />
modprobe tpm_tis<br />
modprobe tpm<br />
#OAT-Sever's info<br />
OAT_SERVER_IP=10.239.48.127<br />
OAT_SERVER_USER=admin<br />
OAT_SERVER_PASSWD=p2<br />
<br />
#Node's IP<br />
DEV=eth1<br />
dhclient $DEV<br />
OAT_CLIENT_IP=$(ip addr show dev $DEV | grep ' inet '| awk '{print $2}'|cut -c -12)<br />
OAT_CLIENT_HOST=$OAT_CLIENT_IP<br />
<br />
#Node's info<br />
bios=NewMLE1<br />
bios_ver=v123<br />
oem_manu=OEM1<br />
vmm=NewMLE2<br />
vmm_ver=v123<br />
os=OS1<br />
os_ver=v1<br />
<br />
#Init OAT-Client<br />
iptables -A INPUT -p tcp --dport 8181 -j ACCEPT<br />
iptables -A INPUT -p tcp --dport 8080 -j ACCEPT<br />
iptables -A INPUT -p tcp --dport 9999 -j ACCEPT<br />
iptables -A INPUT -p tcp --dport 9998 -j ACCEPT<br />
/usr/bin/tagent setup <<EOF<br />
$OAT_SERVER_IP \<br />
<br />
$OAT_SERVER_USER<br />
$OAT_SERVER_PASSWD<br />
EOF<br />
<br />
#register a new host<br />
oat_cert -h $OAT_SERVER_IP<br />
oat_host -a -h $OAT_SERVER_IP "<br />
{\"HostName\":\"$OAT_CLIENT_HOST\",\"IPAddress\":\"$OAT_CLIENT_IP\",\"Port\":\"9999\",\"BIOS_Name\":\"$bios\",\"BIOS_Version\":\"$bios_ver\",\"BIOS_Oem\":\"$oem_manu\",\"VMM_Name\":\"$vmm\",\"VMM_Version\":\"$vmm_ver\",\"VMM_OSName\":\"$os\",\"VMM_OSVersion\":\"$os_ver\",\"Email\":\"\",\"AddOn_Connection_String\":\"\",\"Description\":\"\"}"<br />
<br />
==Manual verify result==<br />
User can install and use oat-command tool to query the trust state of the node<br />
oat_cert -h $OAT_SERVER_IP<br />
oat_pollhosts -h $OAT_SERVER_IP '{"hosts":["$OAT_CLIENT_IP"]}'<br />
<br />
==Limitations and Future Work==<br />
1) Previously, a clean task to rebuild the node with trusted boot was proposed. But it was much<br />
more complicated in Ironic's current framework after investigation. Because the node has to leave clean stage if it wants<br />
to rebuild. A tool which is on the top of Ironic is a better solution so far. It can log the trust<br />
state and trigger Ironic for further steps.<br />
<br />
2) Hot Add/Remove of PCIe devices are not supported. A machine reboot is<br />
necessary to obtain fresh measurements and re-attestation.<br />
<br />
3) Blue Pill<br />
When the hardware virtualization support is enabled without a hypervisor<br />
running, the machine is open to launch a Blue Pill style attack. Unfortunately<br />
OEM vendors do not provide the capability to disable Intel TXT or its<br />
equivalents and those that tried to support the same insisted on establishing<br />
physical presence. The reasoning here is the dynamic control feature itself<br />
could pose a vulnerability. Our goal is unaffected by the Blue Pill aspect<br />
because we are concerned strictly with establishing that a machine prior to<br />
hand-off to a tenant is clean, free of rootkits and malware. Should the tenant<br />
seek to install a rootkit, that is in their purview. Once the machine is<br />
released back to the cloud, our workflow will detect and erase the same.<br />
<br />
This said, no claims of trust or re-attestation of a bare metal machine are<br />
possible post boot time. In the Horizon dashboard re-attest action<br />
will not be provided. Node boot time and trust status at boot time will<br />
be displayed.<br />
<br />
==References==<br />
1. http://sourceforge.net/projects/tboot/<br />
<br />
2. https://github.com/OpenAttestation/OpenAttestation<br />
<br />
3. http://en.wikipedia.org/wiki/Trusted_Platform_Module<br />
<br />
4. http://en.wikipedia.org/wiki/Trusted_Execution_Technology<br />
<br />
5. http://docs.openstack.org/admin-guide-cloud/content/trusted-compute-pools.html</div>Tan Linhttps://wiki.openstack.org/w/index.php?title=Bare-metal-trust&diff=87946Bare-metal-trust2015-08-13T02:54:16Z<p>Tan Lin: /* A typical use case of bare metal trust */</p>
<hr />
<div>==Problem description==<br />
While hypervisors and virtual machines are a common paradigm in the Cloud, heavy compute users seek Bare Metal (BM) to eliminate the performance overhead <br />
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.<br />
<br />
==Proposed solution==<br />
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<br />
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)[3], 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<br />
called TBOOT[1].<br />
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<br />
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<br />
testing is provided by an Open Attestation service, OAT[2]. Additional details in references.<br />
<br />
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.<br />
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<br />
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.<br />
<br />
'''Result:'''<br />
<br />
An OAT client using the customized image verifies the trust state and passes the value to Ironic. A related Horizon blueprint addresses displaying<br />
the trust status of a bare metal node on boot. <br />
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.<br />
<br />
==A typical use case of bare metal trust==<br />
Here is an use case for bare metal trust which will measure each node when it release<br />
<br />
1. Manual work to prepare trusted boot<br />
(enable TXT, VT-x, VT-d, take ownership of the TPM)<br />
2. Set up an OAT-Server<br />
https://github.com/OpenAttestation/OpenAttestation/wiki/<br />
3. Enable trusted boot for Ironic<br />
http://docs.openstack.org/developer/ironic/deploy/install-guide.html#Trusted-boot-with-partition-image<br />
4. Deploy on node and using trusted boot to measure node<br />
(Boot a customized user image with OAT-Client using trusted boot)<br />
(Passing the OAT server URL for attestation)<br />
5. Attestation<br />
(Polls the result from the OAT-Server)<br />
If trusted:<br />
Nodes are available and continue<br />
6. Re-Deploy<br />
Boot guest's image<br />
7. Tenant releases node<br />
Jump to 4<br />
<br />
==Trust Script Example==<br />
Node has to register itself into OAT-Server and wait for attestation, this can be done via boot instance with user-data, here is a sample about the user-data:<br />
<br />
#!/bin/bash -v<br />
modprobe tpm_tis<br />
modprobe tpm<br />
#OAT-Sever's info<br />
OAT_SERVER_IP=10.239.48.127<br />
OAT_SERVER_USER=admin<br />
OAT_SERVER_PASSWD=p2<br />
<br />
#Node's IP<br />
DEV=eth1<br />
dhclient $DEV<br />
OAT_CLIENT_IP=$(ip addr show dev $DEV | grep ' inet '| awk '{print $2}'|cut -c -12)<br />
OAT_CLIENT_HOST=$OAT_CLIENT_IP<br />
<br />
#Node's info<br />
bios=NewMLE1<br />
bios_ver=v123<br />
oem_manu=OEM1<br />
vmm=NewMLE2<br />
vmm_ver=v123<br />
os=OS1<br />
os_ver=v1<br />
<br />
#Init OAT-Client<br />
iptables -A INPUT -p tcp --dport 8181 -j ACCEPT<br />
iptables -A INPUT -p tcp --dport 8080 -j ACCEPT<br />
iptables -A INPUT -p tcp --dport 9999 -j ACCEPT<br />
iptables -A INPUT -p tcp --dport 9998 -j ACCEPT<br />
/usr/bin/tagent setup <<EOF<br />
$OAT_SERVER_IP \<br />
<br />
$OAT_SERVER_USER<br />
$OAT_SERVER_PASSWD<br />
EOF<br />
<br />
#register a new host<br />
oat_cert -h $OAT_SERVER_IP<br />
oat_host -a -h $OAT_SERVER_IP "<br />
{\"HostName\":\"$OAT_CLIENT_HOST\",\"IPAddress\":\"$OAT_CLIENT_IP\",\"Port\":\"9999\",\"BIOS_Name\":\"$bios\",\"BIOS_Version\":\"$bios_ver\",\"BIOS_Oem\":\"$oem_manu\",\"VMM_Name\":\"$vmm\",\"VMM_Version\":\"$vmm_ver\",\"VMM_OSName\":\"$os\",\"VMM_OSVersion\":\"$os_ver\",\"Email\":\"\",\"AddOn_Connection_String\":\"\",\"Description\":\"\"}"<br />
<br />
==Manual verify result==<br />
User can install and use oat-command tool to query the trust state of the node<br />
oat_cert -h $OAT_SERVER_IP<br />
oat_pollhosts -h $OAT_SERVER_IP '{"hosts":["$OAT_CLIENT_IP"]}'<br />
<br />
==Limitations and Future Work==<br />
1) Previously, a clean task to rebuild the node with trusted boot was proposed. But it was much<br />
more complicated in Ironic's current framework after investigation. Because the node has to leave clean stage if it wants<br />
to rebuild. A tool which is on the top of Ironic is a better solution so far. It can log the trust<br />
state and trigger Ironic for further steps.<br />
<br />
2) Hot Add/Remove of PCIe devices are not supported. A machine reboot is<br />
necessary to obtain fresh measurements and re-attestation.<br />
<br />
3) Blue Pill<br />
When the hardware virtualization support is enabled without a hypervisor<br />
running, the machine is open to launch a Blue Pill style attack. Unfortunately<br />
OEM vendors do not provide the capability to disable Intel TXT or its<br />
equivalents and those that tried to support the same insisted on establishing<br />
physical presence. The reasoning here is the dynamic control feature itself<br />
could pose a vulnerability. Our goal is unaffected by the Blue Pill aspect<br />
because we are concerned strictly with establishing that a machine prior to<br />
hand-off to a tenant is clean, free of rootkits and malware. Should the tenant<br />
seek to install a rootkit, that is in their purview. Once the machine is<br />
released back to the cloud, our workflow will detect and erase the same.<br />
<br />
This said, no claims of trust or re-attestation of a bare metal machine are<br />
possible post boot time. In the Horizon dashboard re-attest action<br />
will not be provided. Node boot time and trust status at boot time will<br />
be displayed.<br />
<br />
==References==<br />
1. http://sourceforge.net/projects/tboot/<br />
<br />
2. https://github.com/OpenAttestation/OpenAttestation<br />
<br />
3. http://en.wikipedia.org/wiki/Trusted_Platform_Module<br />
<br />
4. http://en.wikipedia.org/wiki/Trusted_Execution_Technology<br />
<br />
5. http://docs.openstack.org/admin-guide-cloud/content/trusted-compute-pools.html</div>Tan Linhttps://wiki.openstack.org/w/index.php?title=Bare-metal-trust&diff=87945Bare-metal-trust2015-08-13T02:53:51Z<p>Tan Lin: /* A typical use case of bare metal trust */</p>
<hr />
<div>==Problem description==<br />
While hypervisors and virtual machines are a common paradigm in the Cloud, heavy compute users seek Bare Metal (BM) to eliminate the performance overhead <br />
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.<br />
<br />
==Proposed solution==<br />
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<br />
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)[3], 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<br />
called TBOOT[1].<br />
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<br />
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<br />
testing is provided by an Open Attestation service, OAT[2]. Additional details in references.<br />
<br />
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.<br />
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<br />
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.<br />
<br />
'''Result:'''<br />
<br />
An OAT client using the customized image verifies the trust state and passes the value to Ironic. A related Horizon blueprint addresses displaying<br />
the trust status of a bare metal node on boot. <br />
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.<br />
<br />
==A typical use case of bare metal trust==<br />
Here is an use case for bare metal trust which will measure each node when it release<br />
<br />
1. Manual work to prepare trusted boot<br />
(enable TXT, VT-x, VT-d, take ownership of the TPM)<br />
2. Set up an OAT-Server<br />
https://github.com/OpenAttestation/OpenAttestation/wiki/<br />
3. Enable trusted boot for Ironic<br />
http://docs.openstack.org/developer/ironic/deploy/install-guide.html#Trusted-boot-with-partition-image<br />
4. Deploy on node and using trusted boot to measure node<br />
(Boot a customized user image with OAT-Client using trusted boot)<br />
(Passing the OAT server URL for attestation)<br />
5. Attestation<br />
(Polls the result from the OAT-Server)<br />
If trusted:<br />
Nodes are available and continue<br />
6. Re-Deploying<br />
Boot guest's image<br />
7. Tenant releases node<br />
Jump to 4<br />
<br />
==Trust Script Example==<br />
Node has to register itself into OAT-Server and wait for attestation, this can be done via boot instance with user-data, here is a sample about the user-data:<br />
<br />
#!/bin/bash -v<br />
modprobe tpm_tis<br />
modprobe tpm<br />
#OAT-Sever's info<br />
OAT_SERVER_IP=10.239.48.127<br />
OAT_SERVER_USER=admin<br />
OAT_SERVER_PASSWD=p2<br />
<br />
#Node's IP<br />
DEV=eth1<br />
dhclient $DEV<br />
OAT_CLIENT_IP=$(ip addr show dev $DEV | grep ' inet '| awk '{print $2}'|cut -c -12)<br />
OAT_CLIENT_HOST=$OAT_CLIENT_IP<br />
<br />
#Node's info<br />
bios=NewMLE1<br />
bios_ver=v123<br />
oem_manu=OEM1<br />
vmm=NewMLE2<br />
vmm_ver=v123<br />
os=OS1<br />
os_ver=v1<br />
<br />
#Init OAT-Client<br />
iptables -A INPUT -p tcp --dport 8181 -j ACCEPT<br />
iptables -A INPUT -p tcp --dport 8080 -j ACCEPT<br />
iptables -A INPUT -p tcp --dport 9999 -j ACCEPT<br />
iptables -A INPUT -p tcp --dport 9998 -j ACCEPT<br />
/usr/bin/tagent setup <<EOF<br />
$OAT_SERVER_IP \<br />
<br />
$OAT_SERVER_USER<br />
$OAT_SERVER_PASSWD<br />
EOF<br />
<br />
#register a new host<br />
oat_cert -h $OAT_SERVER_IP<br />
oat_host -a -h $OAT_SERVER_IP "<br />
{\"HostName\":\"$OAT_CLIENT_HOST\",\"IPAddress\":\"$OAT_CLIENT_IP\",\"Port\":\"9999\",\"BIOS_Name\":\"$bios\",\"BIOS_Version\":\"$bios_ver\",\"BIOS_Oem\":\"$oem_manu\",\"VMM_Name\":\"$vmm\",\"VMM_Version\":\"$vmm_ver\",\"VMM_OSName\":\"$os\",\"VMM_OSVersion\":\"$os_ver\",\"Email\":\"\",\"AddOn_Connection_String\":\"\",\"Description\":\"\"}"<br />
<br />
==Manual verify result==<br />
User can install and use oat-command tool to query the trust state of the node<br />
oat_cert -h $OAT_SERVER_IP<br />
oat_pollhosts -h $OAT_SERVER_IP '{"hosts":["$OAT_CLIENT_IP"]}'<br />
<br />
==Limitations and Future Work==<br />
1) Previously, a clean task to rebuild the node with trusted boot was proposed. But it was much<br />
more complicated in Ironic's current framework after investigation. Because the node has to leave clean stage if it wants<br />
to rebuild. A tool which is on the top of Ironic is a better solution so far. It can log the trust<br />
state and trigger Ironic for further steps.<br />
<br />
2) Hot Add/Remove of PCIe devices are not supported. A machine reboot is<br />
necessary to obtain fresh measurements and re-attestation.<br />
<br />
3) Blue Pill<br />
When the hardware virtualization support is enabled without a hypervisor<br />
running, the machine is open to launch a Blue Pill style attack. Unfortunately<br />
OEM vendors do not provide the capability to disable Intel TXT or its<br />
equivalents and those that tried to support the same insisted on establishing<br />
physical presence. The reasoning here is the dynamic control feature itself<br />
could pose a vulnerability. Our goal is unaffected by the Blue Pill aspect<br />
because we are concerned strictly with establishing that a machine prior to<br />
hand-off to a tenant is clean, free of rootkits and malware. Should the tenant<br />
seek to install a rootkit, that is in their purview. Once the machine is<br />
released back to the cloud, our workflow will detect and erase the same.<br />
<br />
This said, no claims of trust or re-attestation of a bare metal machine are<br />
possible post boot time. In the Horizon dashboard re-attest action<br />
will not be provided. Node boot time and trust status at boot time will<br />
be displayed.<br />
<br />
==References==<br />
1. http://sourceforge.net/projects/tboot/<br />
<br />
2. https://github.com/OpenAttestation/OpenAttestation<br />
<br />
3. http://en.wikipedia.org/wiki/Trusted_Platform_Module<br />
<br />
4. http://en.wikipedia.org/wiki/Trusted_Execution_Technology<br />
<br />
5. http://docs.openstack.org/admin-guide-cloud/content/trusted-compute-pools.html</div>Tan Linhttps://wiki.openstack.org/w/index.php?title=Bare-metal-trust&diff=87944Bare-metal-trust2015-08-13T02:53:12Z<p>Tan Lin: /* A typical use case of bare metal trust */</p>
<hr />
<div>==Problem description==<br />
While hypervisors and virtual machines are a common paradigm in the Cloud, heavy compute users seek Bare Metal (BM) to eliminate the performance overhead <br />
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.<br />
<br />
==Proposed solution==<br />
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<br />
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)[3], 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<br />
called TBOOT[1].<br />
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<br />
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<br />
testing is provided by an Open Attestation service, OAT[2]. Additional details in references.<br />
<br />
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.<br />
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<br />
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.<br />
<br />
'''Result:'''<br />
<br />
An OAT client using the customized image verifies the trust state and passes the value to Ironic. A related Horizon blueprint addresses displaying<br />
the trust status of a bare metal node on boot. <br />
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.<br />
<br />
==A typical use case of bare metal trust==<br />
Here is an use case for bare metal trust which will measure each node when it release<br />
<br />
1. Manual work to prepare trusted boot<br />
(enable TXT, VT-x, VT-d, take ownership of the TPM)<br />
2. Set up an OAT-Server<br />
https://github.com/OpenAttestation/OpenAttestation/wiki/<br />
3. Enable trusted boot for Ironic<br />
http://docs.openstack.org/developer/ironic/deploy/install-guide.html#Trusted-boot-with-partition-image<br />
4. Deploy on node and using trusted boot to measure Node<br />
(Boot a customized user image with OAT-Client using trusted boot)<br />
(Passing the OAT server URL for attestation)<br />
5. Attestation<br />
(Polls the result from the OAT-Server)<br />
If trusted:<br />
Nodes are available and continue<br />
6. Re-Deploying<br />
Boot guest's image<br />
7. Tenant releases node<br />
Jump to 4<br />
<br />
==Trust Script Example==<br />
Node has to register itself into OAT-Server and wait for attestation, this can be done via boot instance with user-data, here is a sample about the user-data:<br />
<br />
#!/bin/bash -v<br />
modprobe tpm_tis<br />
modprobe tpm<br />
#OAT-Sever's info<br />
OAT_SERVER_IP=10.239.48.127<br />
OAT_SERVER_USER=admin<br />
OAT_SERVER_PASSWD=p2<br />
<br />
#Node's IP<br />
DEV=eth1<br />
dhclient $DEV<br />
OAT_CLIENT_IP=$(ip addr show dev $DEV | grep ' inet '| awk '{print $2}'|cut -c -12)<br />
OAT_CLIENT_HOST=$OAT_CLIENT_IP<br />
<br />
#Node's info<br />
bios=NewMLE1<br />
bios_ver=v123<br />
oem_manu=OEM1<br />
vmm=NewMLE2<br />
vmm_ver=v123<br />
os=OS1<br />
os_ver=v1<br />
<br />
#Init OAT-Client<br />
iptables -A INPUT -p tcp --dport 8181 -j ACCEPT<br />
iptables -A INPUT -p tcp --dport 8080 -j ACCEPT<br />
iptables -A INPUT -p tcp --dport 9999 -j ACCEPT<br />
iptables -A INPUT -p tcp --dport 9998 -j ACCEPT<br />
/usr/bin/tagent setup <<EOF<br />
$OAT_SERVER_IP \<br />
<br />
$OAT_SERVER_USER<br />
$OAT_SERVER_PASSWD<br />
EOF<br />
<br />
#register a new host<br />
oat_cert -h $OAT_SERVER_IP<br />
oat_host -a -h $OAT_SERVER_IP "<br />
{\"HostName\":\"$OAT_CLIENT_HOST\",\"IPAddress\":\"$OAT_CLIENT_IP\",\"Port\":\"9999\",\"BIOS_Name\":\"$bios\",\"BIOS_Version\":\"$bios_ver\",\"BIOS_Oem\":\"$oem_manu\",\"VMM_Name\":\"$vmm\",\"VMM_Version\":\"$vmm_ver\",\"VMM_OSName\":\"$os\",\"VMM_OSVersion\":\"$os_ver\",\"Email\":\"\",\"AddOn_Connection_String\":\"\",\"Description\":\"\"}"<br />
<br />
==Manual verify result==<br />
User can install and use oat-command tool to query the trust state of the node<br />
oat_cert -h $OAT_SERVER_IP<br />
oat_pollhosts -h $OAT_SERVER_IP '{"hosts":["$OAT_CLIENT_IP"]}'<br />
<br />
==Limitations and Future Work==<br />
1) Previously, a clean task to rebuild the node with trusted boot was proposed. But it was much<br />
more complicated in Ironic's current framework after investigation. Because the node has to leave clean stage if it wants<br />
to rebuild. A tool which is on the top of Ironic is a better solution so far. It can log the trust<br />
state and trigger Ironic for further steps.<br />
<br />
2) Hot Add/Remove of PCIe devices are not supported. A machine reboot is<br />
necessary to obtain fresh measurements and re-attestation.<br />
<br />
3) Blue Pill<br />
When the hardware virtualization support is enabled without a hypervisor<br />
running, the machine is open to launch a Blue Pill style attack. Unfortunately<br />
OEM vendors do not provide the capability to disable Intel TXT or its<br />
equivalents and those that tried to support the same insisted on establishing<br />
physical presence. The reasoning here is the dynamic control feature itself<br />
could pose a vulnerability. Our goal is unaffected by the Blue Pill aspect<br />
because we are concerned strictly with establishing that a machine prior to<br />
hand-off to a tenant is clean, free of rootkits and malware. Should the tenant<br />
seek to install a rootkit, that is in their purview. Once the machine is<br />
released back to the cloud, our workflow will detect and erase the same.<br />
<br />
This said, no claims of trust or re-attestation of a bare metal machine are<br />
possible post boot time. In the Horizon dashboard re-attest action<br />
will not be provided. Node boot time and trust status at boot time will<br />
be displayed.<br />
<br />
==References==<br />
1. http://sourceforge.net/projects/tboot/<br />
<br />
2. https://github.com/OpenAttestation/OpenAttestation<br />
<br />
3. http://en.wikipedia.org/wiki/Trusted_Platform_Module<br />
<br />
4. http://en.wikipedia.org/wiki/Trusted_Execution_Technology<br />
<br />
5. http://docs.openstack.org/admin-guide-cloud/content/trusted-compute-pools.html</div>Tan Linhttps://wiki.openstack.org/w/index.php?title=Bare-metal-trust&diff=87840Bare-metal-trust2015-08-12T07:47:59Z<p>Tan Lin: /* Manual verify result */</p>
<hr />
<div>==Problem description==<br />
While hypervisors and virtual machines are a common paradigm in the Cloud, heavy compute users seek Bare Metal (BM) to eliminate the performance overhead <br />
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.<br />
<br />
==Proposed solution==<br />
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<br />
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)[3], 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<br />
called TBOOT[1].<br />
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<br />
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<br />
testing is provided by an Open Attestation service, OAT[2]. Additional details in references.<br />
<br />
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.<br />
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<br />
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.<br />
<br />
'''Result:'''<br />
<br />
An OAT client using the customized image verifies the trust state and passes the value to Ironic. A related Horizon blueprint addresses displaying<br />
the trust status of a bare metal node on boot. <br />
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.<br />
<br />
==A typical use case of bare metal trust==<br />
Here is an use case for bare metal trust which will measure each node when it release<br />
<br />
1. Manual work to prepare trusted boot<br />
(enable TXT, VT-x, VT-d, take ownership of the TPM)<br />
2. Set up an OAT-Server<br />
https://github.com/OpenAttestation/OpenAttestation/wiki/<br />
3. Enable trusted boot for Ironic<br />
http://docs.openstack.org/developer/ironic/deploy/install-guide.html#Trusted-boot-with-partition-image<br />
4. Deploy a trusted boot node<br />
(Boot a customized image with OAT-Client using trusted boot)<br />
(Passing the OAT server URL for attestation)<br />
5. Attestation<br />
(Polls the result from the OAT-Server)<br />
If trusted:<br />
Nodes are available and continue<br />
6. Deploying<br />
Boot guest image<br />
7. Tenant releases node<br />
Jump to 4<br />
<br />
==Trust Script Example==<br />
Node has to register itself into OAT-Server and wait for attestation, this can be done via boot instance with user-data, here is a sample about the user-data:<br />
<br />
#!/bin/bash -v<br />
modprobe tpm_tis<br />
modprobe tpm<br />
#OAT-Sever's info<br />
OAT_SERVER_IP=10.239.48.127<br />
OAT_SERVER_USER=admin<br />
OAT_SERVER_PASSWD=p2<br />
<br />
#Node's IP<br />
DEV=eth1<br />
dhclient $DEV<br />
OAT_CLIENT_IP=$(ip addr show dev $DEV | grep ' inet '| awk '{print $2}'|cut -c -12)<br />
OAT_CLIENT_HOST=$OAT_CLIENT_IP<br />
<br />
#Node's info<br />
bios=NewMLE1<br />
bios_ver=v123<br />
oem_manu=OEM1<br />
vmm=NewMLE2<br />
vmm_ver=v123<br />
os=OS1<br />
os_ver=v1<br />
<br />
#Init OAT-Client<br />
iptables -A INPUT -p tcp --dport 8181 -j ACCEPT<br />
iptables -A INPUT -p tcp --dport 8080 -j ACCEPT<br />
iptables -A INPUT -p tcp --dport 9999 -j ACCEPT<br />
iptables -A INPUT -p tcp --dport 9998 -j ACCEPT<br />
/usr/bin/tagent setup <<EOF<br />
$OAT_SERVER_IP \<br />
<br />
$OAT_SERVER_USER<br />
$OAT_SERVER_PASSWD<br />
EOF<br />
<br />
#register a new host<br />
oat_cert -h $OAT_SERVER_IP<br />
oat_host -a -h $OAT_SERVER_IP "<br />
{\"HostName\":\"$OAT_CLIENT_HOST\",\"IPAddress\":\"$OAT_CLIENT_IP\",\"Port\":\"9999\",\"BIOS_Name\":\"$bios\",\"BIOS_Version\":\"$bios_ver\",\"BIOS_Oem\":\"$oem_manu\",\"VMM_Name\":\"$vmm\",\"VMM_Version\":\"$vmm_ver\",\"VMM_OSName\":\"$os\",\"VMM_OSVersion\":\"$os_ver\",\"Email\":\"\",\"AddOn_Connection_String\":\"\",\"Description\":\"\"}"<br />
<br />
==Manual verify result==<br />
User can install and use oat-command tool to query the trust state of the node<br />
oat_cert -h $OAT_SERVER_IP<br />
oat_pollhosts -h $OAT_SERVER_IP '{"hosts":["$OAT_CLIENT_IP"]}'<br />
<br />
==Limitations and Future Work==<br />
1) Previously, a clean task to rebuild the node with trusted boot was proposed. But it was much<br />
more complicated in Ironic's current framework after investigation. Because the node has to leave clean stage if it wants<br />
to rebuild. A tool which is on the top of Ironic is a better solution so far. It can log the trust<br />
state and trigger Ironic for further steps.<br />
<br />
2) Hot Add/Remove of PCIe devices are not supported. A machine reboot is<br />
necessary to obtain fresh measurements and re-attestation.<br />
<br />
3) Blue Pill<br />
When the hardware virtualization support is enabled without a hypervisor<br />
running, the machine is open to launch a Blue Pill style attack. Unfortunately<br />
OEM vendors do not provide the capability to disable Intel TXT or its<br />
equivalents and those that tried to support the same insisted on establishing<br />
physical presence. The reasoning here is the dynamic control feature itself<br />
could pose a vulnerability. Our goal is unaffected by the Blue Pill aspect<br />
because we are concerned strictly with establishing that a machine prior to<br />
hand-off to a tenant is clean, free of rootkits and malware. Should the tenant<br />
seek to install a rootkit, that is in their purview. Once the machine is<br />
released back to the cloud, our workflow will detect and erase the same.<br />
<br />
This said, no claims of trust or re-attestation of a bare metal machine are<br />
possible post boot time. In the Horizon dashboard re-attest action<br />
will not be provided. Node boot time and trust status at boot time will<br />
be displayed.<br />
<br />
==References==<br />
1. http://sourceforge.net/projects/tboot/<br />
<br />
2. https://github.com/OpenAttestation/OpenAttestation<br />
<br />
3. http://en.wikipedia.org/wiki/Trusted_Platform_Module<br />
<br />
4. http://en.wikipedia.org/wiki/Trusted_Execution_Technology<br />
<br />
5. http://docs.openstack.org/admin-guide-cloud/content/trusted-compute-pools.html</div>Tan Linhttps://wiki.openstack.org/w/index.php?title=Bare-metal-trust&diff=87839Bare-metal-trust2015-08-12T07:47:28Z<p>Tan Lin: /* Manual verify result */</p>
<hr />
<div>==Problem description==<br />
While hypervisors and virtual machines are a common paradigm in the Cloud, heavy compute users seek Bare Metal (BM) to eliminate the performance overhead <br />
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.<br />
<br />
==Proposed solution==<br />
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<br />
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)[3], 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<br />
called TBOOT[1].<br />
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<br />
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<br />
testing is provided by an Open Attestation service, OAT[2]. Additional details in references.<br />
<br />
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.<br />
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<br />
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.<br />
<br />
'''Result:'''<br />
<br />
An OAT client using the customized image verifies the trust state and passes the value to Ironic. A related Horizon blueprint addresses displaying<br />
the trust status of a bare metal node on boot. <br />
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.<br />
<br />
==A typical use case of bare metal trust==<br />
Here is an use case for bare metal trust which will measure each node when it release<br />
<br />
1. Manual work to prepare trusted boot<br />
(enable TXT, VT-x, VT-d, take ownership of the TPM)<br />
2. Set up an OAT-Server<br />
https://github.com/OpenAttestation/OpenAttestation/wiki/<br />
3. Enable trusted boot for Ironic<br />
http://docs.openstack.org/developer/ironic/deploy/install-guide.html#Trusted-boot-with-partition-image<br />
4. Deploy a trusted boot node<br />
(Boot a customized image with OAT-Client using trusted boot)<br />
(Passing the OAT server URL for attestation)<br />
5. Attestation<br />
(Polls the result from the OAT-Server)<br />
If trusted:<br />
Nodes are available and continue<br />
6. Deploying<br />
Boot guest image<br />
7. Tenant releases node<br />
Jump to 4<br />
<br />
==Trust Script Example==<br />
Node has to register itself into OAT-Server and wait for attestation, this can be done via boot instance with user-data, here is a sample about the user-data:<br />
<br />
#!/bin/bash -v<br />
modprobe tpm_tis<br />
modprobe tpm<br />
#OAT-Sever's info<br />
OAT_SERVER_IP=10.239.48.127<br />
OAT_SERVER_USER=admin<br />
OAT_SERVER_PASSWD=p2<br />
<br />
#Node's IP<br />
DEV=eth1<br />
dhclient $DEV<br />
OAT_CLIENT_IP=$(ip addr show dev $DEV | grep ' inet '| awk '{print $2}'|cut -c -12)<br />
OAT_CLIENT_HOST=$OAT_CLIENT_IP<br />
<br />
#Node's info<br />
bios=NewMLE1<br />
bios_ver=v123<br />
oem_manu=OEM1<br />
vmm=NewMLE2<br />
vmm_ver=v123<br />
os=OS1<br />
os_ver=v1<br />
<br />
#Init OAT-Client<br />
iptables -A INPUT -p tcp --dport 8181 -j ACCEPT<br />
iptables -A INPUT -p tcp --dport 8080 -j ACCEPT<br />
iptables -A INPUT -p tcp --dport 9999 -j ACCEPT<br />
iptables -A INPUT -p tcp --dport 9998 -j ACCEPT<br />
/usr/bin/tagent setup <<EOF<br />
$OAT_SERVER_IP \<br />
<br />
$OAT_SERVER_USER<br />
$OAT_SERVER_PASSWD<br />
EOF<br />
<br />
#register a new host<br />
oat_cert -h $OAT_SERVER_IP<br />
oat_host -a -h $OAT_SERVER_IP "<br />
{\"HostName\":\"$OAT_CLIENT_HOST\",\"IPAddress\":\"$OAT_CLIENT_IP\",\"Port\":\"9999\",\"BIOS_Name\":\"$bios\",\"BIOS_Version\":\"$bios_ver\",\"BIOS_Oem\":\"$oem_manu\",\"VMM_Name\":\"$vmm\",\"VMM_Version\":\"$vmm_ver\",\"VMM_OSName\":\"$os\",\"VMM_OSVersion\":\"$os_ver\",\"Email\":\"\",\"AddOn_Connection_String\":\"\",\"Description\":\"\"}"<br />
<br />
==Manual verify result==<br />
User can use oat-command tool to query the trust state of the node<br />
oat_cert -h $OAT_SERVER_IP<br />
oat_pollhosts -h $OAT_SERVER_IP '{"hosts":["$OAT_CLIENT_IP"]}'<br />
<br />
==Limitations and Future Work==<br />
1) Previously, a clean task to rebuild the node with trusted boot was proposed. But it was much<br />
more complicated in Ironic's current framework after investigation. Because the node has to leave clean stage if it wants<br />
to rebuild. A tool which is on the top of Ironic is a better solution so far. It can log the trust<br />
state and trigger Ironic for further steps.<br />
<br />
2) Hot Add/Remove of PCIe devices are not supported. A machine reboot is<br />
necessary to obtain fresh measurements and re-attestation.<br />
<br />
3) Blue Pill<br />
When the hardware virtualization support is enabled without a hypervisor<br />
running, the machine is open to launch a Blue Pill style attack. Unfortunately<br />
OEM vendors do not provide the capability to disable Intel TXT or its<br />
equivalents and those that tried to support the same insisted on establishing<br />
physical presence. The reasoning here is the dynamic control feature itself<br />
could pose a vulnerability. Our goal is unaffected by the Blue Pill aspect<br />
because we are concerned strictly with establishing that a machine prior to<br />
hand-off to a tenant is clean, free of rootkits and malware. Should the tenant<br />
seek to install a rootkit, that is in their purview. Once the machine is<br />
released back to the cloud, our workflow will detect and erase the same.<br />
<br />
This said, no claims of trust or re-attestation of a bare metal machine are<br />
possible post boot time. In the Horizon dashboard re-attest action<br />
will not be provided. Node boot time and trust status at boot time will<br />
be displayed.<br />
<br />
==References==<br />
1. http://sourceforge.net/projects/tboot/<br />
<br />
2. https://github.com/OpenAttestation/OpenAttestation<br />
<br />
3. http://en.wikipedia.org/wiki/Trusted_Platform_Module<br />
<br />
4. http://en.wikipedia.org/wiki/Trusted_Execution_Technology<br />
<br />
5. http://docs.openstack.org/admin-guide-cloud/content/trusted-compute-pools.html</div>Tan Linhttps://wiki.openstack.org/w/index.php?title=Bare-metal-trust&diff=87837Bare-metal-trust2015-08-12T06:52:54Z<p>Tan Lin: /* Limitations and Future Work */</p>
<hr />
<div>==Problem description==<br />
While hypervisors and virtual machines are a common paradigm in the Cloud, heavy compute users seek Bare Metal (BM) to eliminate the performance overhead <br />
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.<br />
<br />
==Proposed solution==<br />
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<br />
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)[3], 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<br />
called TBOOT[1].<br />
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<br />
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<br />
testing is provided by an Open Attestation service, OAT[2]. Additional details in references.<br />
<br />
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.<br />
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<br />
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.<br />
<br />
'''Result:'''<br />
<br />
An OAT client using the customized image verifies the trust state and passes the value to Ironic. A related Horizon blueprint addresses displaying<br />
the trust status of a bare metal node on boot. <br />
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.<br />
<br />
==A typical use case of bare metal trust==<br />
Here is an use case for bare metal trust which will measure each node when it release<br />
<br />
1. Manual work to prepare trusted boot<br />
(enable TXT, VT-x, VT-d, take ownership of the TPM)<br />
2. Set up an OAT-Server<br />
https://github.com/OpenAttestation/OpenAttestation/wiki/<br />
3. Enable trusted boot for Ironic<br />
http://docs.openstack.org/developer/ironic/deploy/install-guide.html#Trusted-boot-with-partition-image<br />
4. Deploy a trusted boot node<br />
(Boot a customized image with OAT-Client using trusted boot)<br />
(Passing the OAT server URL for attestation)<br />
5. Attestation<br />
(Polls the result from the OAT-Server)<br />
If trusted:<br />
Nodes are available and continue<br />
6. Deploying<br />
Boot guest image<br />
7. Tenant releases node<br />
Jump to 4<br />
<br />
==Trust Script Example==<br />
Node has to register itself into OAT-Server and wait for attestation, this can be done via boot instance with user-data, here is a sample about the user-data:<br />
<br />
#!/bin/bash -v<br />
modprobe tpm_tis<br />
modprobe tpm<br />
#OAT-Sever's info<br />
OAT_SERVER_IP=10.239.48.127<br />
OAT_SERVER_USER=admin<br />
OAT_SERVER_PASSWD=p2<br />
<br />
#Node's IP<br />
DEV=eth1<br />
dhclient $DEV<br />
OAT_CLIENT_IP=$(ip addr show dev $DEV | grep ' inet '| awk '{print $2}'|cut -c -12)<br />
OAT_CLIENT_HOST=$OAT_CLIENT_IP<br />
<br />
#Node's info<br />
bios=NewMLE1<br />
bios_ver=v123<br />
oem_manu=OEM1<br />
vmm=NewMLE2<br />
vmm_ver=v123<br />
os=OS1<br />
os_ver=v1<br />
<br />
#Init OAT-Client<br />
iptables -A INPUT -p tcp --dport 8181 -j ACCEPT<br />
iptables -A INPUT -p tcp --dport 8080 -j ACCEPT<br />
iptables -A INPUT -p tcp --dport 9999 -j ACCEPT<br />
iptables -A INPUT -p tcp --dport 9998 -j ACCEPT<br />
/usr/bin/tagent setup <<EOF<br />
$OAT_SERVER_IP \<br />
<br />
$OAT_SERVER_USER<br />
$OAT_SERVER_PASSWD<br />
EOF<br />
<br />
#register a new host<br />
oat_cert -h $OAT_SERVER_IP<br />
oat_host -a -h $OAT_SERVER_IP "<br />
{\"HostName\":\"$OAT_CLIENT_HOST\",\"IPAddress\":\"$OAT_CLIENT_IP\",\"Port\":\"9999\",\"BIOS_Name\":\"$bios\",\"BIOS_Version\":\"$bios_ver\",\"BIOS_Oem\":\"$oem_manu\",\"VMM_Name\":\"$vmm\",\"VMM_Version\":\"$vmm_ver\",\"VMM_OSName\":\"$os\",\"VMM_OSVersion\":\"$os_ver\",\"Email\":\"\",\"AddOn_Connection_String\":\"\",\"Description\":\"\"}"<br />
<br />
==Manual verify result==<br />
User can use oat-command tool to query the trust state of the node<br />
<br />
oat_pollhosts -h $OAT_SERVER_IP '{"hosts":["$OAT_CLIENT_IP"]}'<br />
<br />
==Limitations and Future Work==<br />
1) Previously, a clean task to rebuild the node with trusted boot was proposed. But it was much<br />
more complicated in Ironic's current framework after investigation. Because the node has to leave clean stage if it wants<br />
to rebuild. A tool which is on the top of Ironic is a better solution so far. It can log the trust<br />
state and trigger Ironic for further steps.<br />
<br />
2) Hot Add/Remove of PCIe devices are not supported. A machine reboot is<br />
necessary to obtain fresh measurements and re-attestation.<br />
<br />
3) Blue Pill<br />
When the hardware virtualization support is enabled without a hypervisor<br />
running, the machine is open to launch a Blue Pill style attack. Unfortunately<br />
OEM vendors do not provide the capability to disable Intel TXT or its<br />
equivalents and those that tried to support the same insisted on establishing<br />
physical presence. The reasoning here is the dynamic control feature itself<br />
could pose a vulnerability. Our goal is unaffected by the Blue Pill aspect<br />
because we are concerned strictly with establishing that a machine prior to<br />
hand-off to a tenant is clean, free of rootkits and malware. Should the tenant<br />
seek to install a rootkit, that is in their purview. Once the machine is<br />
released back to the cloud, our workflow will detect and erase the same.<br />
<br />
This said, no claims of trust or re-attestation of a bare metal machine are<br />
possible post boot time. In the Horizon dashboard re-attest action<br />
will not be provided. Node boot time and trust status at boot time will<br />
be displayed.<br />
<br />
==References==<br />
1. http://sourceforge.net/projects/tboot/<br />
<br />
2. https://github.com/OpenAttestation/OpenAttestation<br />
<br />
3. http://en.wikipedia.org/wiki/Trusted_Platform_Module<br />
<br />
4. http://en.wikipedia.org/wiki/Trusted_Execution_Technology<br />
<br />
5. http://docs.openstack.org/admin-guide-cloud/content/trusted-compute-pools.html</div>Tan Linhttps://wiki.openstack.org/w/index.php?title=Bare-metal-trust&diff=87836Bare-metal-trust2015-08-12T06:44:52Z<p>Tan Lin: /* Work flow */</p>
<hr />
<div>==Problem description==<br />
While hypervisors and virtual machines are a common paradigm in the Cloud, heavy compute users seek Bare Metal (BM) to eliminate the performance overhead <br />
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.<br />
<br />
==Proposed solution==<br />
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<br />
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)[3], 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<br />
called TBOOT[1].<br />
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<br />
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<br />
testing is provided by an Open Attestation service, OAT[2]. Additional details in references.<br />
<br />
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.<br />
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<br />
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.<br />
<br />
'''Result:'''<br />
<br />
An OAT client using the customized image verifies the trust state and passes the value to Ironic. A related Horizon blueprint addresses displaying<br />
the trust status of a bare metal node on boot. <br />
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.<br />
<br />
==A typical use case of bare metal trust==<br />
Here is an use case for bare metal trust which will measure each node when it release<br />
<br />
1. Manual work to prepare trusted boot<br />
(enable TXT, VT-x, VT-d, take ownership of the TPM)<br />
2. Set up an OAT-Server<br />
https://github.com/OpenAttestation/OpenAttestation/wiki/<br />
3. Enable trusted boot for Ironic<br />
http://docs.openstack.org/developer/ironic/deploy/install-guide.html#Trusted-boot-with-partition-image<br />
4. Deploy a trusted boot node<br />
(Boot a customized image with OAT-Client using trusted boot)<br />
(Passing the OAT server URL for attestation)<br />
5. Attestation<br />
(Polls the result from the OAT-Server)<br />
If trusted:<br />
Nodes are available and continue<br />
6. Deploying<br />
Boot guest image<br />
7. Tenant releases node<br />
Jump to 4<br />
<br />
==Trust Script Example==<br />
Node has to register itself into OAT-Server and wait for attestation, this can be done via boot instance with user-data, here is a sample about the user-data:<br />
<br />
#!/bin/bash -v<br />
modprobe tpm_tis<br />
modprobe tpm<br />
#OAT-Sever's info<br />
OAT_SERVER_IP=10.239.48.127<br />
OAT_SERVER_USER=admin<br />
OAT_SERVER_PASSWD=p2<br />
<br />
#Node's IP<br />
DEV=eth1<br />
dhclient $DEV<br />
OAT_CLIENT_IP=$(ip addr show dev $DEV | grep ' inet '| awk '{print $2}'|cut -c -12)<br />
OAT_CLIENT_HOST=$OAT_CLIENT_IP<br />
<br />
#Node's info<br />
bios=NewMLE1<br />
bios_ver=v123<br />
oem_manu=OEM1<br />
vmm=NewMLE2<br />
vmm_ver=v123<br />
os=OS1<br />
os_ver=v1<br />
<br />
#Init OAT-Client<br />
iptables -A INPUT -p tcp --dport 8181 -j ACCEPT<br />
iptables -A INPUT -p tcp --dport 8080 -j ACCEPT<br />
iptables -A INPUT -p tcp --dport 9999 -j ACCEPT<br />
iptables -A INPUT -p tcp --dport 9998 -j ACCEPT<br />
/usr/bin/tagent setup <<EOF<br />
$OAT_SERVER_IP \<br />
<br />
$OAT_SERVER_USER<br />
$OAT_SERVER_PASSWD<br />
EOF<br />
<br />
#register a new host<br />
oat_cert -h $OAT_SERVER_IP<br />
oat_host -a -h $OAT_SERVER_IP "<br />
{\"HostName\":\"$OAT_CLIENT_HOST\",\"IPAddress\":\"$OAT_CLIENT_IP\",\"Port\":\"9999\",\"BIOS_Name\":\"$bios\",\"BIOS_Version\":\"$bios_ver\",\"BIOS_Oem\":\"$oem_manu\",\"VMM_Name\":\"$vmm\",\"VMM_Version\":\"$vmm_ver\",\"VMM_OSName\":\"$os\",\"VMM_OSVersion\":\"$os_ver\",\"Email\":\"\",\"AddOn_Connection_String\":\"\",\"Description\":\"\"}"<br />
<br />
==Manual verify result==<br />
User can use oat-command tool to query the trust state of the node<br />
<br />
oat_pollhosts -h $OAT_SERVER_IP '{"hosts":["$OAT_CLIENT_IP"]}'<br />
<br />
==Limitations and Future Work==<br />
1) Previously, a clean task to rebuild the node with trusted boot was proposed. But it was much<br />
more complicated in Ironic's current framework after investigation. Because the node has to leave clean stage if it wants<br />
to rebuild. A third-party tool who is on the top of Ironic is a better solution so far. It can log the trust<br />
state and trigger Ironic for further steps.<br />
<br />
2) Hot Add/Remove of PCIe devices are not supported. A machine reboot is<br />
necessary to obtain fresh measurements and re-attestation.<br />
<br />
3) Blue Pill<br />
When the hardware virtualization support is enabled without a hypervisor<br />
running, the machine is open to launch a Blue Pill style attack. Unfortunately<br />
OEM vendors do not provide the capability to disable Intel TXT or its<br />
equivalents and those that tried to support the same insisted on establishing<br />
physical presence. The reasoning here is the dynamic control feature itself<br />
could pose a vulnerability. Our goal is unaffected by the Blue Pill aspect<br />
because we are concerned strictly with establishing that a machine prior to<br />
hand-off to a tenant is clean, free of rootkits and malware. Should the tenant<br />
seek to install a rootkit, that is in their purview. Once the machine is<br />
released back to the cloud, our workflow will detect and erase the same.<br />
<br />
This said, no claims of trust or re-attestation of a bare metal machine are<br />
possible post boot time. In the Horizon dashboard re-attest action<br />
will not be provided. Node boot time and trust status at boot time will<br />
be displayed.<br />
<br />
==References==<br />
1. http://sourceforge.net/projects/tboot/<br />
<br />
2. https://github.com/OpenAttestation/OpenAttestation<br />
<br />
3. http://en.wikipedia.org/wiki/Trusted_Platform_Module<br />
<br />
4. http://en.wikipedia.org/wiki/Trusted_Execution_Technology<br />
<br />
5. http://docs.openstack.org/admin-guide-cloud/content/trusted-compute-pools.html</div>Tan Linhttps://wiki.openstack.org/w/index.php?title=Bare-metal-trust&diff=87834Bare-metal-trust2015-08-12T06:12:32Z<p>Tan Lin: </p>
<hr />
<div>==Problem description==<br />
While hypervisors and virtual machines are a common paradigm in the Cloud, heavy compute users seek Bare Metal (BM) to eliminate the performance overhead <br />
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.<br />
<br />
==Proposed solution==<br />
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<br />
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)[3], 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<br />
called TBOOT[1].<br />
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<br />
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<br />
testing is provided by an Open Attestation service, OAT[2]. Additional details in references.<br />
<br />
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.<br />
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<br />
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.<br />
<br />
'''Result:'''<br />
<br />
An OAT client using the customized image verifies the trust state and passes the value to Ironic. A related Horizon blueprint addresses displaying<br />
the trust status of a bare metal node on boot. <br />
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.<br />
<br />
==Work flow==<br />
Note BIOS re-flash and automatic enable TXT will not be available soon.<br />
<br />
1. Manual work to prepare trusted boot<br />
(enable TXT, VT-x, VT-d, take ownership of the TPM)<br />
2. Set up an OAT-Server<br />
https://github.com/OpenAttestation/OpenAttestation/wiki/Fedora-oat-2.2-packages-installation<br />
3. Enable trusted boot for Ironic<br />
http://docs.openstack.org/developer/ironic/deploy/install-guide.html#Trusted-boot-with-partition-image<br />
4. Deploy a trusted boot node<br />
(Boot a customized image with OAT-Client using trusted boot)<br />
(Passing the OAT server URL for attestation)<br />
5. Attestation<br />
(Polls the result from the OAT-Server)<br />
If trusted:<br />
Nodes are available and Jump to 5<br />
6. Deploying<br />
Boot guest image using trusted boot<br />
7. Tenant releases node<br />
<br />
8. Jump to 4<br />
<br />
==Trust Script Example==<br />
Node has to register itself into OAT-Server and wait for attestation, this can be done via boot instance with user-data, here is a sample about the user-data:<br />
<br />
#!/bin/bash -v<br />
modprobe tpm_tis<br />
modprobe tpm<br />
#OAT-Sever's info<br />
OAT_SERVER_IP=10.239.48.127<br />
OAT_SERVER_USER=admin<br />
OAT_SERVER_PASSWD=p2<br />
<br />
#Node's IP<br />
DEV=eth1<br />
dhclient $DEV<br />
OAT_CLIENT_IP=$(ip addr show dev $DEV | grep ' inet '| awk '{print $2}'|cut -c -12)<br />
OAT_CLIENT_HOST=$OAT_CLIENT_IP<br />
<br />
#Node's info<br />
bios=NewMLE1<br />
bios_ver=v123<br />
oem_manu=OEM1<br />
vmm=NewMLE2<br />
vmm_ver=v123<br />
os=OS1<br />
os_ver=v1<br />
<br />
#Init OAT-Client<br />
iptables -A INPUT -p tcp --dport 8181 -j ACCEPT<br />
iptables -A INPUT -p tcp --dport 8080 -j ACCEPT<br />
iptables -A INPUT -p tcp --dport 9999 -j ACCEPT<br />
iptables -A INPUT -p tcp --dport 9998 -j ACCEPT<br />
/usr/bin/tagent setup <<EOF<br />
$OAT_SERVER_IP \<br />
<br />
$OAT_SERVER_USER<br />
$OAT_SERVER_PASSWD<br />
EOF<br />
<br />
#register a new host<br />
oat_cert -h $OAT_SERVER_IP<br />
oat_host -a -h $OAT_SERVER_IP "<br />
{\"HostName\":\"$OAT_CLIENT_HOST\",\"IPAddress\":\"$OAT_CLIENT_IP\",\"Port\":\"9999\",\"BIOS_Name\":\"$bios\",\"BIOS_Version\":\"$bios_ver\",\"BIOS_Oem\":\"$oem_manu\",\"VMM_Name\":\"$vmm\",\"VMM_Version\":\"$vmm_ver\",\"VMM_OSName\":\"$os\",\"VMM_OSVersion\":\"$os_ver\",\"Email\":\"\",\"AddOn_Connection_String\":\"\",\"Description\":\"\"}"<br />
<br />
==Manual verify result==<br />
User can use oat-command tool to query the trust state of the node<br />
<br />
oat_pollhosts -h $OAT_SERVER_IP '{"hosts":["$OAT_CLIENT_IP"]}'<br />
<br />
==Limitations and Future Work==<br />
1) Previously, a clean task to rebuild the node with trusted boot was proposed. But it was much<br />
more complicated in Ironic's current framework after investigation. Because the node has to leave clean stage if it wants<br />
to rebuild. A third-party tool who is on the top of Ironic is a better solution so far. It can log the trust<br />
state and trigger Ironic for further steps.<br />
<br />
2) Hot Add/Remove of PCIe devices are not supported. A machine reboot is<br />
necessary to obtain fresh measurements and re-attestation.<br />
<br />
3) Blue Pill<br />
When the hardware virtualization support is enabled without a hypervisor<br />
running, the machine is open to launch a Blue Pill style attack. Unfortunately<br />
OEM vendors do not provide the capability to disable Intel TXT or its<br />
equivalents and those that tried to support the same insisted on establishing<br />
physical presence. The reasoning here is the dynamic control feature itself<br />
could pose a vulnerability. Our goal is unaffected by the Blue Pill aspect<br />
because we are concerned strictly with establishing that a machine prior to<br />
hand-off to a tenant is clean, free of rootkits and malware. Should the tenant<br />
seek to install a rootkit, that is in their purview. Once the machine is<br />
released back to the cloud, our workflow will detect and erase the same.<br />
<br />
This said, no claims of trust or re-attestation of a bare metal machine are<br />
possible post boot time. In the Horizon dashboard re-attest action<br />
will not be provided. Node boot time and trust status at boot time will<br />
be displayed.<br />
<br />
==References==<br />
1. http://sourceforge.net/projects/tboot/<br />
<br />
2. https://github.com/OpenAttestation/OpenAttestation<br />
<br />
3. http://en.wikipedia.org/wiki/Trusted_Platform_Module<br />
<br />
4. http://en.wikipedia.org/wiki/Trusted_Execution_Technology<br />
<br />
5. http://docs.openstack.org/admin-guide-cloud/content/trusted-compute-pools.html</div>Tan Linhttps://wiki.openstack.org/w/index.php?title=Bare-metal-trust&diff=87833Bare-metal-trust2015-08-12T06:11:43Z<p>Tan Lin: /* Manual verify result */</p>
<hr />
<div>==Problem description==<br />
While hypervisors and virtual machines are a common paradigm in the Cloud, heavy compute users seek Bare Metal (BM) to eliminate the performance overhead <br />
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.<br />
<br />
==Proposed solution==<br />
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<br />
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)[3], 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<br />
called TBOOT[1].<br />
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<br />
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<br />
testing is provided by an Open Attestation service, OAT[2]. Additional details in references.<br />
<br />
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.<br />
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<br />
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.<br />
<br />
'''Result:'''<br />
<br />
An OAT client using the customized image verifies the trust state and passes the value to Ironic. A related Horizon blueprint addresses displaying<br />
the trust status of a bare metal node on boot. <br />
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.<br />
<br />
==Work flow==<br />
Note BIOS re-flash and automatic enable TXT will not be available soon.<br />
<br />
1. Manual work to prepare trusted boot<br />
(enable TXT, VT-x, VT-d, take ownership of the TPM)<br />
2. Set up an OAT-Server<br />
https://github.com/OpenAttestation/OpenAttestation/wiki/Fedora-oat-2.2-packages-installation<br />
3. Enable trusted boot for Ironic<br />
http://docs.openstack.org/developer/ironic/deploy/install-guide.html#Trusted-boot-with-partition-image<br />
4. Deploy a trusted boot node<br />
(Boot a customized image with OAT-Client using trusted boot)<br />
(Passing the OAT server URL for attestation)<br />
5. Attestation<br />
(Polls the result from the OAT-Server)<br />
If trusted:<br />
Nodes are available and Jump to 5<br />
6. Deploying<br />
Boot guest image using trusted boot<br />
7. Tenant releases node<br />
<br />
8. Jump to 4<br />
<br />
==Trust Script Example==<br />
Node has to register itself into OAT-Server and wait for attestation, this can be done via boot instance with user-data, here is a sample about the user-data:<br />
<br />
#!/bin/bash -v<br />
modprobe tpm_tis<br />
modprobe tpm<br />
#OAT-Sever's info<br />
OAT_SERVER_IP=10.239.48.127<br />
OAT_SERVER_USER=admin<br />
OAT_SERVER_PASSWD=p2<br />
<br />
#Node's IP<br />
DEV=eth1<br />
dhclient $DEV<br />
OAT_CLIENT_IP=$(ip addr show dev $DEV | grep ' inet '| awk '{print $2}'|cut -c -12)<br />
OAT_CLIENT_HOST=$OAT_CLIENT_IP<br />
<br />
#Node's info<br />
bios=NewMLE1<br />
bios_ver=v123<br />
oem_manu=OEM1<br />
vmm=NewMLE2<br />
vmm_ver=v123<br />
os=OS1<br />
os_ver=v1<br />
<br />
#Init OAT-Client<br />
iptables -A INPUT -p tcp --dport 8181 -j ACCEPT<br />
iptables -A INPUT -p tcp --dport 8080 -j ACCEPT<br />
iptables -A INPUT -p tcp --dport 9999 -j ACCEPT<br />
iptables -A INPUT -p tcp --dport 9998 -j ACCEPT<br />
/usr/bin/tagent setup <<EOF<br />
$OAT_SERVER_IP \<br />
<br />
$OAT_SERVER_USER<br />
$OAT_SERVER_PASSWD<br />
EOF<br />
<br />
#register a new host<br />
oat_cert -h $OAT_SERVER_IP<br />
oat_host -a -h $OAT_SERVER_IP "<br />
{\"HostName\":\"$OAT_CLIENT_HOST\",\"IPAddress\":\"$OAT_CLIENT_IP\",\"Port\":\"9999\",\"BIOS_Name\":\"$bios\",\"BIOS_Version\":\"$bios_ver\",\"BIOS_Oem\":\"$oem_manu\",\"VMM_Name\":\"$vmm\",\"VMM_Version\":\"$vmm_ver\",\"VMM_OSName\":\"$os\",\"VMM_OSVersion\":\"$os_ver\",\"Email\":\"\",\"AddOn_Connection_String\":\"\",\"Description\":\"\"}"<br />
<br />
==Manual verify result==<br />
User can use oat-command tool to query the trust state of the node<br />
<br />
oat_pollhosts -h $OAT_SERVER_IP '{"hosts":["$OAT_CLIENT_IP"]}'<br />
<br />
==Limitations and Future Work==<br />
1) Previously, a clean task to rebuild the node with trusted boot was proposed. But it was much<br />
more complicated in Ironic's current framework after investigation. Because the node has to leave clean stage if it wants<br />
to rebuild. A third-party tool who is on the top of Ironic is a better solution so far. It can log the trust<br />
state and trigger Ironic for further steps.<br />
<br />
2) Hot Add/Remove of PCIe devices are not supported. A machine reboot is<br />
necessary to obtain fresh measurements and re-attestation.<br />
<br />
3) Blue Pill<br />
When the hardware virtualization support is enabled without a hypervisor<br />
running, the machine is open to launch a Blue Pill style attack. Unfortunately<br />
OEM vendors do not provide the capability to disable Intel TXT or its<br />
equivalents and those that tried to support the same insisted on establishing<br />
physical presence. The reasoning here is the dynamic control feature itself<br />
could pose a vulnerability. Our goal is unaffected by the Blue Pill aspect<br />
because we are concerned strictly with establishing that a machine prior to<br />
hand-off to a tenant is clean, free of rootkits and malware. Should the tenant<br />
seek to install a rootkit, that is in their purview. Once the machine is<br />
released back to the cloud, our workflow will detect and erase the same.<br />
<br />
This said, no claims of trust or re-attestation of a bare metal machine are<br />
possible post boot time. In the Horizon dashboard re-attest action<br />
will not be provided. Node boot time and trust status at boot time will<br />
be displayed.<br />
<br />
==References==<br />
1. http://sourceforge.net/projects/tboot/<br />
<br />
2. https://github.com/OpenAttestation/OpenAttestation<br />
<br />
3. http://en.wikipedia.org/wiki/Trusted_Platform_Module<br />
<br />
4. http://en.wikipedia.org/wiki/Trusted_Execution_Technology<br />
<br />
5. http://docs.openstack.org/admin-guide-cloud/content/trusted-compute-pools.html</div>Tan Linhttps://wiki.openstack.org/w/index.php?title=Bare-metal-trust&diff=87832Bare-metal-trust2015-08-12T06:10:35Z<p>Tan Lin: </p>
<hr />
<div>==Problem description==<br />
While hypervisors and virtual machines are a common paradigm in the Cloud, heavy compute users seek Bare Metal (BM) to eliminate the performance overhead <br />
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.<br />
<br />
==Proposed solution==<br />
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<br />
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)[3], 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<br />
called TBOOT[1].<br />
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<br />
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<br />
testing is provided by an Open Attestation service, OAT[2]. Additional details in references.<br />
<br />
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.<br />
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<br />
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.<br />
<br />
'''Result:'''<br />
<br />
An OAT client using the customized image verifies the trust state and passes the value to Ironic. A related Horizon blueprint addresses displaying<br />
the trust status of a bare metal node on boot. <br />
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.<br />
<br />
==Work flow==<br />
Note BIOS re-flash and automatic enable TXT will not be available soon.<br />
<br />
1. Manual work to prepare trusted boot<br />
(enable TXT, VT-x, VT-d, take ownership of the TPM)<br />
2. Set up an OAT-Server<br />
https://github.com/OpenAttestation/OpenAttestation/wiki/Fedora-oat-2.2-packages-installation<br />
3. Enable trusted boot for Ironic<br />
http://docs.openstack.org/developer/ironic/deploy/install-guide.html#Trusted-boot-with-partition-image<br />
4. Deploy a trusted boot node<br />
(Boot a customized image with OAT-Client using trusted boot)<br />
(Passing the OAT server URL for attestation)<br />
5. Attestation<br />
(Polls the result from the OAT-Server)<br />
If trusted:<br />
Nodes are available and Jump to 5<br />
6. Deploying<br />
Boot guest image using trusted boot<br />
7. Tenant releases node<br />
<br />
8. Jump to 4<br />
<br />
==Trust Script Example==<br />
Node has to register itself into OAT-Server and wait for attestation, this can be done via boot instance with user-data, here is a sample about the user-data:<br />
<br />
#!/bin/bash -v<br />
modprobe tpm_tis<br />
modprobe tpm<br />
#OAT-Sever's info<br />
OAT_SERVER_IP=10.239.48.127<br />
OAT_SERVER_USER=admin<br />
OAT_SERVER_PASSWD=p2<br />
<br />
#Node's IP<br />
DEV=eth1<br />
dhclient $DEV<br />
OAT_CLIENT_IP=$(ip addr show dev $DEV | grep ' inet '| awk '{print $2}'|cut -c -12)<br />
OAT_CLIENT_HOST=$OAT_CLIENT_IP<br />
<br />
#Node's info<br />
bios=NewMLE1<br />
bios_ver=v123<br />
oem_manu=OEM1<br />
vmm=NewMLE2<br />
vmm_ver=v123<br />
os=OS1<br />
os_ver=v1<br />
<br />
#Init OAT-Client<br />
iptables -A INPUT -p tcp --dport 8181 -j ACCEPT<br />
iptables -A INPUT -p tcp --dport 8080 -j ACCEPT<br />
iptables -A INPUT -p tcp --dport 9999 -j ACCEPT<br />
iptables -A INPUT -p tcp --dport 9998 -j ACCEPT<br />
/usr/bin/tagent setup <<EOF<br />
$OAT_SERVER_IP \<br />
<br />
$OAT_SERVER_USER<br />
$OAT_SERVER_PASSWD<br />
EOF<br />
<br />
#register a new host<br />
oat_cert -h $OAT_SERVER_IP<br />
oat_host -a -h $OAT_SERVER_IP "<br />
{\"HostName\":\"$OAT_CLIENT_HOST\",\"IPAddress\":\"$OAT_CLIENT_IP\",\"Port\":\"9999\",\"BIOS_Name\":\"$bios\",\"BIOS_Version\":\"$bios_ver\",\"BIOS_Oem\":\"$oem_manu\",\"VMM_Name\":\"$vmm\",\"VMM_Version\":\"$vmm_ver\",\"VMM_OSName\":\"$os\",\"VMM_OSVersion\":\"$os_ver\",\"Email\":\"\",\"AddOn_Connection_String\":\"\",\"Description\":\"\"}"<br />
<br />
==Manual verify result==<br />
User can use oat-command tool to query the trust state of the node<br />
oat_pollhosts -h $OAT_SERVER_IP '{"hosts":["$OAT_CLIENT_IP"]}'<br />
<br />
==Limitations and Future Work==<br />
1) Previously, a clean task to rebuild the node with trusted boot was proposed. But it was much<br />
more complicated in Ironic's current framework after investigation. Because the node has to leave clean stage if it wants<br />
to rebuild. A third-party tool who is on the top of Ironic is a better solution so far. It can log the trust<br />
state and trigger Ironic for further steps.<br />
<br />
2) Hot Add/Remove of PCIe devices are not supported. A machine reboot is<br />
necessary to obtain fresh measurements and re-attestation.<br />
<br />
3) Blue Pill<br />
When the hardware virtualization support is enabled without a hypervisor<br />
running, the machine is open to launch a Blue Pill style attack. Unfortunately<br />
OEM vendors do not provide the capability to disable Intel TXT or its<br />
equivalents and those that tried to support the same insisted on establishing<br />
physical presence. The reasoning here is the dynamic control feature itself<br />
could pose a vulnerability. Our goal is unaffected by the Blue Pill aspect<br />
because we are concerned strictly with establishing that a machine prior to<br />
hand-off to a tenant is clean, free of rootkits and malware. Should the tenant<br />
seek to install a rootkit, that is in their purview. Once the machine is<br />
released back to the cloud, our workflow will detect and erase the same.<br />
<br />
This said, no claims of trust or re-attestation of a bare metal machine are<br />
possible post boot time. In the Horizon dashboard re-attest action<br />
will not be provided. Node boot time and trust status at boot time will<br />
be displayed.<br />
<br />
==References==<br />
1. http://sourceforge.net/projects/tboot/<br />
<br />
2. https://github.com/OpenAttestation/OpenAttestation<br />
<br />
3. http://en.wikipedia.org/wiki/Trusted_Platform_Module<br />
<br />
4. http://en.wikipedia.org/wiki/Trusted_Execution_Technology<br />
<br />
5. http://docs.openstack.org/admin-guide-cloud/content/trusted-compute-pools.html</div>Tan Linhttps://wiki.openstack.org/w/index.php?title=Bare-metal-trust&diff=87221Bare-metal-trust2015-08-03T11:24:28Z<p>Tan Lin: /* Limitations and Future Work */</p>
<hr />
<div>==Problem description==<br />
While hypervisors and virtual machines are a common paradigm in the Cloud, heavy compute users seek Bare Metal (BM) to eliminate the performance overhead <br />
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.<br />
<br />
==Proposed solution==<br />
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<br />
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)[3], 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<br />
called TBOOT[1].<br />
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<br />
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<br />
testing is provided by an Open Attestation service, OAT[2]. Additional details in references.<br />
<br />
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.<br />
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<br />
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.<br />
<br />
'''Result:'''<br />
<br />
An OAT client using the customized image verifies the trust state and passes the value to Ironic. A related Horizon blueprint addresses displaying<br />
the trust status of a bare metal node on boot. <br />
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.<br />
<br />
==Work flow==<br />
Note BIOS re-flash and automatic enable TXT will not be available soon.<br />
<br />
1. Manual work to prepare trusted boot<br />
(enable TXT, VT-x, VT-d, take ownership of the TPM)<br />
2. Set up an OAT-Server<br />
https://github.com/OpenAttestation/OpenAttestation/wiki/Fedora-oat-2.2-packages-installation<br />
3. Enable trusted boot for Ironic<br />
http://docs.openstack.org/developer/ironic/deploy/install-guide.html#Trusted-boot-with-partition-image<br />
4. Deploy a trusted boot node<br />
(Boot a customized image with OAT-Client using trusted boot)<br />
(Passing the OAT server URL for attestation)<br />
5. Attestation<br />
(Polls the result from the OAT-Server)<br />
If trusted:<br />
Nodes are available and Jump to 5<br />
6. Deploying<br />
Boot guest image using trusted boot<br />
7. Tenant releases node<br />
<br />
8. Jump to 4<br />
<br />
==Attestation==<br />
1. Node has to register itself into OAT-Server and wait for attestation, this can be done via boot instance with user-data, here is a sample about the user-data:<br />
<br />
#!/bin/bash -v<br />
modprobe tpm_tis<br />
modprobe tpm<br />
#OAT-Sever's info<br />
OAT_SERVER_IP=10.239.48.127<br />
OAT_SERVER_USER=admin<br />
OAT_SERVER_PASSWD=p2<br />
<br />
#Node's IP<br />
DEV=eth1<br />
dhclient $DEV<br />
OAT_CLIENT_IP=$(ip addr show dev $DEV | grep ' inet '| awk '{print $2}'|cut -c -12)<br />
OAT_CLIENT_HOST=$OAT_CLIENT_IP<br />
<br />
#Node's info<br />
bios=NewMLE1<br />
bios_ver=v123<br />
oem_manu=OEM1<br />
vmm=NewMLE2<br />
vmm_ver=v123<br />
os=OS1<br />
os_ver=v1<br />
<br />
#Init OAT-Client<br />
iptables -A INPUT -p tcp --dport 8181 -j ACCEPT<br />
iptables -A INPUT -p tcp --dport 8080 -j ACCEPT<br />
iptables -A INPUT -p tcp --dport 9999 -j ACCEPT<br />
iptables -A INPUT -p tcp --dport 9998 -j ACCEPT<br />
/usr/bin/tagent setup <<EOF<br />
$OAT_SERVER_IP \<br />
<br />
$OAT_SERVER_USER<br />
$OAT_SERVER_PASSWD<br />
EOF<br />
<br />
#register a new host<br />
oat_cert -h $OAT_SERVER_IP<br />
oat_host -a -h $OAT_SERVER_IP "<br />
{\"HostName\":\"$OAT_CLIENT_HOST\",\"IPAddress\":\"$OAT_CLIENT_IP\",\"Port\":\"9999\",\"BIOS_Name\":\"$bios\",\"BIOS_Version\":\"$bios_ver\",\"BIOS_Oem\":\"$oem_manu\",\"VMM_Name\":\"$vmm\",\"VMM_Version\":\"$vmm_ver\",\"VMM_OSName\":\"$os\",\"VMM_OSVersion\":\"$os_ver\",\"Email\":\"\",\"AddOn_Connection_String\":\"\",\"Description\":\"\"}"<br />
<br />
2. Then using oat-command tool to query the trust state of the node,<br />
oat_pollhosts -h $OAT_SERVER_IP '{"hosts":["$OAT_CLIENT_IP"]}'<br />
<br />
==Limitations and Future Work==<br />
1) Previously, a clean task to rebuild the node with trusted boot was proposed. But it was much<br />
more complicated in Ironic's current framework after investigation. Because the node has to leave clean stage if it wants<br />
to rebuild. A third-party tool who is on the top of Ironic is a better solution so far. It can log the trust<br />
state and trigger Ironic for further steps.<br />
<br />
2) Hot Add/Remove of PCIe devices are not supported. A machine reboot is<br />
necessary to obtain fresh measurements and re-attestation.<br />
<br />
3) Blue Pill<br />
When the hardware virtualization support is enabled without a hypervisor<br />
running, the machine is open to launch a Blue Pill style attack. Unfortunately<br />
OEM vendors do not provide the capability to disable Intel TXT or its<br />
equivalents and those that tried to support the same insisted on establishing<br />
physical presence. The reasoning here is the dynamic control feature itself<br />
could pose a vulnerability. Our goal is unaffected by the Blue Pill aspect<br />
because we are concerned strictly with establishing that a machine prior to<br />
hand-off to a tenant is clean, free of rootkits and malware. Should the tenant<br />
seek to install a rootkit, that is in their purview. Once the machine is<br />
released back to the cloud, our workflow will detect and erase the same.<br />
<br />
This said, no claims of trust or re-attestation of a bare metal machine are<br />
possible post boot time. In the Horizon dashboard re-attest action<br />
will not be provided. Node boot time and trust status at boot time will<br />
be displayed.<br />
<br />
==References==<br />
1. http://sourceforge.net/projects/tboot/<br />
<br />
2. https://github.com/OpenAttestation/OpenAttestation<br />
<br />
3. http://en.wikipedia.org/wiki/Trusted_Platform_Module<br />
<br />
4. http://en.wikipedia.org/wiki/Trusted_Execution_Technology<br />
<br />
5. http://docs.openstack.org/admin-guide-cloud/content/trusted-compute-pools.html</div>Tan Linhttps://wiki.openstack.org/w/index.php?title=Bare-metal-trust&diff=87220Bare-metal-trust2015-08-03T11:14:04Z<p>Tan Lin: /* Work flow */</p>
<hr />
<div>==Problem description==<br />
While hypervisors and virtual machines are a common paradigm in the Cloud, heavy compute users seek Bare Metal (BM) to eliminate the performance overhead <br />
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.<br />
<br />
==Proposed solution==<br />
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<br />
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)[3], 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<br />
called TBOOT[1].<br />
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<br />
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<br />
testing is provided by an Open Attestation service, OAT[2]. Additional details in references.<br />
<br />
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.<br />
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<br />
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.<br />
<br />
'''Result:'''<br />
<br />
An OAT client using the customized image verifies the trust state and passes the value to Ironic. A related Horizon blueprint addresses displaying<br />
the trust status of a bare metal node on boot. <br />
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.<br />
<br />
==Work flow==<br />
Note BIOS re-flash and automatic enable TXT will not be available soon.<br />
<br />
1. Manual work to prepare trusted boot<br />
(enable TXT, VT-x, VT-d, take ownership of the TPM)<br />
2. Set up an OAT-Server<br />
https://github.com/OpenAttestation/OpenAttestation/wiki/Fedora-oat-2.2-packages-installation<br />
3. Enable trusted boot for Ironic<br />
http://docs.openstack.org/developer/ironic/deploy/install-guide.html#Trusted-boot-with-partition-image<br />
4. Deploy a trusted boot node<br />
(Boot a customized image with OAT-Client using trusted boot)<br />
(Passing the OAT server URL for attestation)<br />
5. Attestation<br />
(Polls the result from the OAT-Server)<br />
If trusted:<br />
Nodes are available and Jump to 5<br />
6. Deploying<br />
Boot guest image using trusted boot<br />
7. Tenant releases node<br />
<br />
8. Jump to 4<br />
<br />
==Attestation==<br />
1. Node has to register itself into OAT-Server and wait for attestation, this can be done via boot instance with user-data, here is a sample about the user-data:<br />
<br />
#!/bin/bash -v<br />
modprobe tpm_tis<br />
modprobe tpm<br />
#OAT-Sever's info<br />
OAT_SERVER_IP=10.239.48.127<br />
OAT_SERVER_USER=admin<br />
OAT_SERVER_PASSWD=p2<br />
<br />
#Node's IP<br />
DEV=eth1<br />
dhclient $DEV<br />
OAT_CLIENT_IP=$(ip addr show dev $DEV | grep ' inet '| awk '{print $2}'|cut -c -12)<br />
OAT_CLIENT_HOST=$OAT_CLIENT_IP<br />
<br />
#Node's info<br />
bios=NewMLE1<br />
bios_ver=v123<br />
oem_manu=OEM1<br />
vmm=NewMLE2<br />
vmm_ver=v123<br />
os=OS1<br />
os_ver=v1<br />
<br />
#Init OAT-Client<br />
iptables -A INPUT -p tcp --dport 8181 -j ACCEPT<br />
iptables -A INPUT -p tcp --dport 8080 -j ACCEPT<br />
iptables -A INPUT -p tcp --dport 9999 -j ACCEPT<br />
iptables -A INPUT -p tcp --dport 9998 -j ACCEPT<br />
/usr/bin/tagent setup <<EOF<br />
$OAT_SERVER_IP \<br />
<br />
$OAT_SERVER_USER<br />
$OAT_SERVER_PASSWD<br />
EOF<br />
<br />
#register a new host<br />
oat_cert -h $OAT_SERVER_IP<br />
oat_host -a -h $OAT_SERVER_IP "<br />
{\"HostName\":\"$OAT_CLIENT_HOST\",\"IPAddress\":\"$OAT_CLIENT_IP\",\"Port\":\"9999\",\"BIOS_Name\":\"$bios\",\"BIOS_Version\":\"$bios_ver\",\"BIOS_Oem\":\"$oem_manu\",\"VMM_Name\":\"$vmm\",\"VMM_Version\":\"$vmm_ver\",\"VMM_OSName\":\"$os\",\"VMM_OSVersion\":\"$os_ver\",\"Email\":\"\",\"AddOn_Connection_String\":\"\",\"Description\":\"\"}"<br />
<br />
2. Then using oat-command tool to query the trust state of the node,<br />
oat_pollhosts -h $OAT_SERVER_IP '{"hosts":["$OAT_CLIENT_IP"]}'<br />
<br />
==Limitations and Future Work==<br />
<br />
1) Hot Add/Remove of PCIe devices are not supported. A machine reboot is<br />
necessary to obtain fresh measurements and re-attestation.<br />
<br />
2) On detecting that a bare metal instance does not meet trust measurements,<br />
we shall log it. In the future, we shall introduce a Ceilometer alert<br />
event to be consumed by the cloud administrator, perhaps needing follow-up with<br />
the prior tenant. Additionally there is a cleaning step that will address<br />
reflashing BIOS and Option ROMS.<br />
Until reflashed, the untrusted bare metal node will not be allocated to any<br />
tenant.<br />
<br />
3) Blue Pill<br />
When the hardware virtualization support is enabled without a hypervisor<br />
running, the machine is open to launch a Blue Pill style attack. Unfortunately<br />
OEM vendors do not provide the capability to disable Intel TXT or its<br />
equivalents and those that tried to support the same insisted on establishing<br />
physical presence. The reasoning here is the dynamic control feature itself<br />
could pose a vulnerability. Our goal is unaffected by the Blue Pill aspect<br />
because we are concerned strictly with establishing that a machine prior to<br />
hand-off to a tenant is clean, free of rootkits and malware. Should the tenant<br />
seek to install a rootkit, that is in their purview. Once the machine is<br />
released back to the cloud, our workflow will detect and erase the same.<br />
<br />
This said, no claims of trust or re-attestation of a bare metal machine are<br />
possible post boot time. In the Horizon dashboard re-attest action<br />
will not be provided. Node boot time and trust status at boot time will<br />
be displayed.<br />
<br />
==References==<br />
1. http://sourceforge.net/projects/tboot/<br />
<br />
2. https://github.com/OpenAttestation/OpenAttestation<br />
<br />
3. http://en.wikipedia.org/wiki/Trusted_Platform_Module<br />
<br />
4. http://en.wikipedia.org/wiki/Trusted_Execution_Technology<br />
<br />
5. http://docs.openstack.org/admin-guide-cloud/content/trusted-compute-pools.html</div>Tan Linhttps://wiki.openstack.org/w/index.php?title=Bare-metal-trust&diff=87219Bare-metal-trust2015-08-03T11:13:42Z<p>Tan Lin: /* Work flow */</p>
<hr />
<div>==Problem description==<br />
While hypervisors and virtual machines are a common paradigm in the Cloud, heavy compute users seek Bare Metal (BM) to eliminate the performance overhead <br />
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.<br />
<br />
==Proposed solution==<br />
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<br />
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)[3], 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<br />
called TBOOT[1].<br />
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<br />
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<br />
testing is provided by an Open Attestation service, OAT[2]. Additional details in references.<br />
<br />
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.<br />
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<br />
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.<br />
<br />
'''Result:'''<br />
<br />
An OAT client using the customized image verifies the trust state and passes the value to Ironic. A related Horizon blueprint addresses displaying<br />
the trust status of a bare metal node on boot. <br />
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.<br />
<br />
==Work flow==<br />
Note BIOS re-flash and automatic enable TXT will not be available soon.<br />
<br />
1. Manual work to prepare trusted boot<br />
(enable TXT, VT-x, VT-d, take ownership of the TPM)<br />
2. Set Up a OAT-Server<br />
https://github.com/OpenAttestation/OpenAttestation/wiki/Fedora-oat-2.2-packages-installation<br />
3. Enable trusted boot for Ironic<br />
http://docs.openstack.org/developer/ironic/deploy/install-guide.html#Trusted-boot-with-partition-image<br />
4. Deploy a trusted boot node<br />
(Boot a customized image with OAT-Client using trusted boot)<br />
(Passing the OAT server URL for attestation)<br />
5. Attestation<br />
(Polls the result from the OAT-Server)<br />
If trusted:<br />
Nodes are available and Jump to 5<br />
6. Deploying<br />
Boot guest image using trusted boot<br />
7. Tenant releases node<br />
<br />
8. Jump to 4<br />
<br />
==Attestation==<br />
1. Node has to register itself into OAT-Server and wait for attestation, this can be done via boot instance with user-data, here is a sample about the user-data:<br />
<br />
#!/bin/bash -v<br />
modprobe tpm_tis<br />
modprobe tpm<br />
#OAT-Sever's info<br />
OAT_SERVER_IP=10.239.48.127<br />
OAT_SERVER_USER=admin<br />
OAT_SERVER_PASSWD=p2<br />
<br />
#Node's IP<br />
DEV=eth1<br />
dhclient $DEV<br />
OAT_CLIENT_IP=$(ip addr show dev $DEV | grep ' inet '| awk '{print $2}'|cut -c -12)<br />
OAT_CLIENT_HOST=$OAT_CLIENT_IP<br />
<br />
#Node's info<br />
bios=NewMLE1<br />
bios_ver=v123<br />
oem_manu=OEM1<br />
vmm=NewMLE2<br />
vmm_ver=v123<br />
os=OS1<br />
os_ver=v1<br />
<br />
#Init OAT-Client<br />
iptables -A INPUT -p tcp --dport 8181 -j ACCEPT<br />
iptables -A INPUT -p tcp --dport 8080 -j ACCEPT<br />
iptables -A INPUT -p tcp --dport 9999 -j ACCEPT<br />
iptables -A INPUT -p tcp --dport 9998 -j ACCEPT<br />
/usr/bin/tagent setup <<EOF<br />
$OAT_SERVER_IP \<br />
<br />
$OAT_SERVER_USER<br />
$OAT_SERVER_PASSWD<br />
EOF<br />
<br />
#register a new host<br />
oat_cert -h $OAT_SERVER_IP<br />
oat_host -a -h $OAT_SERVER_IP "<br />
{\"HostName\":\"$OAT_CLIENT_HOST\",\"IPAddress\":\"$OAT_CLIENT_IP\",\"Port\":\"9999\",\"BIOS_Name\":\"$bios\",\"BIOS_Version\":\"$bios_ver\",\"BIOS_Oem\":\"$oem_manu\",\"VMM_Name\":\"$vmm\",\"VMM_Version\":\"$vmm_ver\",\"VMM_OSName\":\"$os\",\"VMM_OSVersion\":\"$os_ver\",\"Email\":\"\",\"AddOn_Connection_String\":\"\",\"Description\":\"\"}"<br />
<br />
2. Then using oat-command tool to query the trust state of the node,<br />
oat_pollhosts -h $OAT_SERVER_IP '{"hosts":["$OAT_CLIENT_IP"]}'<br />
<br />
==Limitations and Future Work==<br />
<br />
1) Hot Add/Remove of PCIe devices are not supported. A machine reboot is<br />
necessary to obtain fresh measurements and re-attestation.<br />
<br />
2) On detecting that a bare metal instance does not meet trust measurements,<br />
we shall log it. In the future, we shall introduce a Ceilometer alert<br />
event to be consumed by the cloud administrator, perhaps needing follow-up with<br />
the prior tenant. Additionally there is a cleaning step that will address<br />
reflashing BIOS and Option ROMS.<br />
Until reflashed, the untrusted bare metal node will not be allocated to any<br />
tenant.<br />
<br />
3) Blue Pill<br />
When the hardware virtualization support is enabled without a hypervisor<br />
running, the machine is open to launch a Blue Pill style attack. Unfortunately<br />
OEM vendors do not provide the capability to disable Intel TXT or its<br />
equivalents and those that tried to support the same insisted on establishing<br />
physical presence. The reasoning here is the dynamic control feature itself<br />
could pose a vulnerability. Our goal is unaffected by the Blue Pill aspect<br />
because we are concerned strictly with establishing that a machine prior to<br />
hand-off to a tenant is clean, free of rootkits and malware. Should the tenant<br />
seek to install a rootkit, that is in their purview. Once the machine is<br />
released back to the cloud, our workflow will detect and erase the same.<br />
<br />
This said, no claims of trust or re-attestation of a bare metal machine are<br />
possible post boot time. In the Horizon dashboard re-attest action<br />
will not be provided. Node boot time and trust status at boot time will<br />
be displayed.<br />
<br />
==References==<br />
1. http://sourceforge.net/projects/tboot/<br />
<br />
2. https://github.com/OpenAttestation/OpenAttestation<br />
<br />
3. http://en.wikipedia.org/wiki/Trusted_Platform_Module<br />
<br />
4. http://en.wikipedia.org/wiki/Trusted_Execution_Technology<br />
<br />
5. http://docs.openstack.org/admin-guide-cloud/content/trusted-compute-pools.html</div>Tan Linhttps://wiki.openstack.org/w/index.php?title=Bare-metal-trust&diff=87218Bare-metal-trust2015-08-03T11:11:54Z<p>Tan Lin: /* How to pass OAT-Server URL */</p>
<hr />
<div>==Problem description==<br />
While hypervisors and virtual machines are a common paradigm in the Cloud, heavy compute users seek Bare Metal (BM) to eliminate the performance overhead <br />
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.<br />
<br />
==Proposed solution==<br />
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<br />
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)[3], 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<br />
called TBOOT[1].<br />
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<br />
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<br />
testing is provided by an Open Attestation service, OAT[2]. Additional details in references.<br />
<br />
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.<br />
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<br />
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.<br />
<br />
'''Result:'''<br />
<br />
An OAT client using the customized image verifies the trust state and passes the value to Ironic. A related Horizon blueprint addresses displaying<br />
the trust status of a bare metal node on boot. <br />
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.<br />
<br />
==Work flow==<br />
Note BIOS re-flash and automatic enable TXT will not be available soon.<br />
<br />
1. Manual work to prepare trusted boot<br />
(enable TXT, VT-x, VT-d, take ownership of the TPM)<br />
2. Enable trusted boot for Ironic<br />
http://docs.openstack.org/developer/ironic/deploy/install-guide.html#Trusted-boot-with-partition-image<br />
3. Deploy a trusted boot node<br />
(Boot a customized image with OAT-Client using trusted boot)<br />
(Passing the OAT server URL for attestation)<br />
4. Attestation<br />
(Polls the result from the OAT-Server)<br />
If trusted:<br />
Nodes are available and Jump to 5<br />
5. Deploying<br />
Boot guest image using trusted boot<br />
6. Tenant releases node<br />
<br />
7. Jump to 3<br />
<br />
==Attestation==<br />
1. Node has to register itself into OAT-Server and wait for attestation, this can be done via boot instance with user-data, here is a sample about the user-data:<br />
<br />
#!/bin/bash -v<br />
modprobe tpm_tis<br />
modprobe tpm<br />
#OAT-Sever's info<br />
OAT_SERVER_IP=10.239.48.127<br />
OAT_SERVER_USER=admin<br />
OAT_SERVER_PASSWD=p2<br />
<br />
#Node's IP<br />
DEV=eth1<br />
dhclient $DEV<br />
OAT_CLIENT_IP=$(ip addr show dev $DEV | grep ' inet '| awk '{print $2}'|cut -c -12)<br />
OAT_CLIENT_HOST=$OAT_CLIENT_IP<br />
<br />
#Node's info<br />
bios=NewMLE1<br />
bios_ver=v123<br />
oem_manu=OEM1<br />
vmm=NewMLE2<br />
vmm_ver=v123<br />
os=OS1<br />
os_ver=v1<br />
<br />
#Init OAT-Client<br />
iptables -A INPUT -p tcp --dport 8181 -j ACCEPT<br />
iptables -A INPUT -p tcp --dport 8080 -j ACCEPT<br />
iptables -A INPUT -p tcp --dport 9999 -j ACCEPT<br />
iptables -A INPUT -p tcp --dport 9998 -j ACCEPT<br />
/usr/bin/tagent setup <<EOF<br />
$OAT_SERVER_IP \<br />
<br />
$OAT_SERVER_USER<br />
$OAT_SERVER_PASSWD<br />
EOF<br />
<br />
#register a new host<br />
oat_cert -h $OAT_SERVER_IP<br />
oat_host -a -h $OAT_SERVER_IP "<br />
{\"HostName\":\"$OAT_CLIENT_HOST\",\"IPAddress\":\"$OAT_CLIENT_IP\",\"Port\":\"9999\",\"BIOS_Name\":\"$bios\",\"BIOS_Version\":\"$bios_ver\",\"BIOS_Oem\":\"$oem_manu\",\"VMM_Name\":\"$vmm\",\"VMM_Version\":\"$vmm_ver\",\"VMM_OSName\":\"$os\",\"VMM_OSVersion\":\"$os_ver\",\"Email\":\"\",\"AddOn_Connection_String\":\"\",\"Description\":\"\"}"<br />
<br />
2. Then using oat-command tool to query the trust state of the node,<br />
oat_pollhosts -h $OAT_SERVER_IP '{"hosts":["$OAT_CLIENT_IP"]}'<br />
<br />
==Limitations and Future Work==<br />
<br />
1) Hot Add/Remove of PCIe devices are not supported. A machine reboot is<br />
necessary to obtain fresh measurements and re-attestation.<br />
<br />
2) On detecting that a bare metal instance does not meet trust measurements,<br />
we shall log it. In the future, we shall introduce a Ceilometer alert<br />
event to be consumed by the cloud administrator, perhaps needing follow-up with<br />
the prior tenant. Additionally there is a cleaning step that will address<br />
reflashing BIOS and Option ROMS.<br />
Until reflashed, the untrusted bare metal node will not be allocated to any<br />
tenant.<br />
<br />
3) Blue Pill<br />
When the hardware virtualization support is enabled without a hypervisor<br />
running, the machine is open to launch a Blue Pill style attack. Unfortunately<br />
OEM vendors do not provide the capability to disable Intel TXT or its<br />
equivalents and those that tried to support the same insisted on establishing<br />
physical presence. The reasoning here is the dynamic control feature itself<br />
could pose a vulnerability. Our goal is unaffected by the Blue Pill aspect<br />
because we are concerned strictly with establishing that a machine prior to<br />
hand-off to a tenant is clean, free of rootkits and malware. Should the tenant<br />
seek to install a rootkit, that is in their purview. Once the machine is<br />
released back to the cloud, our workflow will detect and erase the same.<br />
<br />
This said, no claims of trust or re-attestation of a bare metal machine are<br />
possible post boot time. In the Horizon dashboard re-attest action<br />
will not be provided. Node boot time and trust status at boot time will<br />
be displayed.<br />
<br />
==References==<br />
1. http://sourceforge.net/projects/tboot/<br />
<br />
2. https://github.com/OpenAttestation/OpenAttestation<br />
<br />
3. http://en.wikipedia.org/wiki/Trusted_Platform_Module<br />
<br />
4. http://en.wikipedia.org/wiki/Trusted_Execution_Technology<br />
<br />
5. http://docs.openstack.org/admin-guide-cloud/content/trusted-compute-pools.html</div>Tan Linhttps://wiki.openstack.org/w/index.php?title=Bare-metal-trust&diff=87215Bare-metal-trust2015-08-03T11:00:12Z<p>Tan Lin: /* Proposed solution */</p>
<hr />
<div>==Problem description==<br />
While hypervisors and virtual machines are a common paradigm in the Cloud, heavy compute users seek Bare Metal (BM) to eliminate the performance overhead <br />
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.<br />
<br />
==Proposed solution==<br />
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<br />
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)[3], 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<br />
called TBOOT[1].<br />
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<br />
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<br />
testing is provided by an Open Attestation service, OAT[2]. Additional details in references.<br />
<br />
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.<br />
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<br />
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.<br />
<br />
'''Result:'''<br />
<br />
An OAT client using the customized image verifies the trust state and passes the value to Ironic. A related Horizon blueprint addresses displaying<br />
the trust status of a bare metal node on boot. <br />
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.<br />
<br />
==Work flow==<br />
Note BIOS re-flash and automatic enable TXT will not be available soon.<br />
<br />
1. Manual work to prepare trusted boot<br />
(enable TXT, VT-x, VT-d, take ownership of the TPM)<br />
2. Enable trusted boot for Ironic<br />
http://docs.openstack.org/developer/ironic/deploy/install-guide.html#Trusted-boot-with-partition-image<br />
3. Deploy a trusted boot node<br />
(Boot a customized image with OAT-Client using trusted boot)<br />
(Passing the OAT server URL for attestation)<br />
4. Attestation<br />
(Polls the result from the OAT-Server)<br />
If trusted:<br />
Nodes are available and Jump to 5<br />
5. Deploying<br />
Boot guest image using trusted boot<br />
6. Tenant releases node<br />
<br />
7. Jump to 3<br />
<br />
==How to pass OAT-Server URL==<br />
This can be done via boot instance with user-data, here is a sample about the user-data:<br />
<br />
#!/bin/bash -v<br />
modprobe tpm_tis<br />
modprobe tpm<br />
#OAT-Sever's info<br />
OAT_SERVER_IP=10.239.48.127<br />
OAT_SERVER_USER=admin<br />
OAT_SERVER_PASSWD=p2<br />
<br />
#Node's IP<br />
DEV=eth1<br />
dhclient $DEV<br />
OAT_CLIENT_IP=$(ip addr show dev $DEV | grep ' inet '| awk '{print $2}'|cut -c -12)<br />
OAT_CLIENT_HOST=$OAT_CLIENT_IP<br />
<br />
#Node's info<br />
bios=NewMLE1<br />
bios_ver=v123<br />
oem_manu=OEM1<br />
vmm=NewMLE2<br />
vmm_ver=v123<br />
os=OS1<br />
os_ver=v1<br />
<br />
#Init OAT-Client<br />
iptables -A INPUT -p tcp --dport 8181 -j ACCEPT<br />
iptables -A INPUT -p tcp --dport 8080 -j ACCEPT<br />
iptables -A INPUT -p tcp --dport 9999 -j ACCEPT<br />
iptables -A INPUT -p tcp --dport 9998 -j ACCEPT<br />
/usr/bin/tagent setup <<EOF<br />
$OAT_SERVER_IP \<br />
<br />
$OAT_SERVER_USER<br />
$OAT_SERVER_PASSWD<br />
EOF<br />
<br />
#register a new host<br />
oat_cert -h $OAT_SERVER_IP<br />
oat_host -a -h $OAT_SERVER_IP "<br />
{\"HostName\":\"$OAT_CLIENT_HOST\",\"IPAddress\":\"$OAT_CLIENT_IP\",\"Port\":\"9999\",\"BIOS_Name\":\"$bios\",\"BIOS_Version\":\"$bios_ver\",\"BIOS_Oem\":\"$oem_manu\",\"VMM_Name\":\"$vmm\",\"VMM_Version\":\"$vmm_ver\",\"VMM_OSName\":\"$os\",\"VMM_OSVersion\":\"$os_ver\",\"Email\":\"\",\"AddOn_Connection_String\":\"\",\"Description\":\"\"}"<br />
<br />
==Limitations and Future Work==<br />
<br />
1) Hot Add/Remove of PCIe devices are not supported. A machine reboot is<br />
necessary to obtain fresh measurements and re-attestation.<br />
<br />
2) On detecting that a bare metal instance does not meet trust measurements,<br />
we shall log it. In the future, we shall introduce a Ceilometer alert<br />
event to be consumed by the cloud administrator, perhaps needing follow-up with<br />
the prior tenant. Additionally there is a cleaning step that will address<br />
reflashing BIOS and Option ROMS.<br />
Until reflashed, the untrusted bare metal node will not be allocated to any<br />
tenant.<br />
<br />
3) Blue Pill<br />
When the hardware virtualization support is enabled without a hypervisor<br />
running, the machine is open to launch a Blue Pill style attack. Unfortunately<br />
OEM vendors do not provide the capability to disable Intel TXT or its<br />
equivalents and those that tried to support the same insisted on establishing<br />
physical presence. The reasoning here is the dynamic control feature itself<br />
could pose a vulnerability. Our goal is unaffected by the Blue Pill aspect<br />
because we are concerned strictly with establishing that a machine prior to<br />
hand-off to a tenant is clean, free of rootkits and malware. Should the tenant<br />
seek to install a rootkit, that is in their purview. Once the machine is<br />
released back to the cloud, our workflow will detect and erase the same.<br />
<br />
This said, no claims of trust or re-attestation of a bare metal machine are<br />
possible post boot time. In the Horizon dashboard re-attest action<br />
will not be provided. Node boot time and trust status at boot time will<br />
be displayed.<br />
<br />
==References==<br />
1. http://sourceforge.net/projects/tboot/<br />
<br />
2. https://github.com/OpenAttestation/OpenAttestation<br />
<br />
3. http://en.wikipedia.org/wiki/Trusted_Platform_Module<br />
<br />
4. http://en.wikipedia.org/wiki/Trusted_Execution_Technology<br />
<br />
5. http://docs.openstack.org/admin-guide-cloud/content/trusted-compute-pools.html</div>Tan Linhttps://wiki.openstack.org/w/index.php?title=Bare-metal-trust&diff=87214Bare-metal-trust2015-08-03T10:59:51Z<p>Tan Lin: /* Proposed solution */</p>
<hr />
<div>==Problem description==<br />
While hypervisors and virtual machines are a common paradigm in the Cloud, heavy compute users seek Bare Metal (BM) to eliminate the performance overhead <br />
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.<br />
<br />
==Proposed solution==<br />
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<br />
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)[3], 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<br />
called TBOOT[1].<br />
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<br />
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<br />
testing is provided by an Open Attestation service, OAT[2]. Additional details in references.<br />
<br />
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.<br />
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<br />
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.<br />
<br />
'''Result:'''<br />
<br />
An OAT client using the customized image verifies the trust state and passes the value to Ironic. The related Horizon blueprint [12] addresses displaying<br />
the trust status of a bare metal node on boot. <br />
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.<br />
<br />
==Work flow==<br />
Note BIOS re-flash and automatic enable TXT will not be available soon.<br />
<br />
1. Manual work to prepare trusted boot<br />
(enable TXT, VT-x, VT-d, take ownership of the TPM)<br />
2. Enable trusted boot for Ironic<br />
http://docs.openstack.org/developer/ironic/deploy/install-guide.html#Trusted-boot-with-partition-image<br />
3. Deploy a trusted boot node<br />
(Boot a customized image with OAT-Client using trusted boot)<br />
(Passing the OAT server URL for attestation)<br />
4. Attestation<br />
(Polls the result from the OAT-Server)<br />
If trusted:<br />
Nodes are available and Jump to 5<br />
5. Deploying<br />
Boot guest image using trusted boot<br />
6. Tenant releases node<br />
<br />
7. Jump to 3<br />
<br />
==How to pass OAT-Server URL==<br />
This can be done via boot instance with user-data, here is a sample about the user-data:<br />
<br />
#!/bin/bash -v<br />
modprobe tpm_tis<br />
modprobe tpm<br />
#OAT-Sever's info<br />
OAT_SERVER_IP=10.239.48.127<br />
OAT_SERVER_USER=admin<br />
OAT_SERVER_PASSWD=p2<br />
<br />
#Node's IP<br />
DEV=eth1<br />
dhclient $DEV<br />
OAT_CLIENT_IP=$(ip addr show dev $DEV | grep ' inet '| awk '{print $2}'|cut -c -12)<br />
OAT_CLIENT_HOST=$OAT_CLIENT_IP<br />
<br />
#Node's info<br />
bios=NewMLE1<br />
bios_ver=v123<br />
oem_manu=OEM1<br />
vmm=NewMLE2<br />
vmm_ver=v123<br />
os=OS1<br />
os_ver=v1<br />
<br />
#Init OAT-Client<br />
iptables -A INPUT -p tcp --dport 8181 -j ACCEPT<br />
iptables -A INPUT -p tcp --dport 8080 -j ACCEPT<br />
iptables -A INPUT -p tcp --dport 9999 -j ACCEPT<br />
iptables -A INPUT -p tcp --dport 9998 -j ACCEPT<br />
/usr/bin/tagent setup <<EOF<br />
$OAT_SERVER_IP \<br />
<br />
$OAT_SERVER_USER<br />
$OAT_SERVER_PASSWD<br />
EOF<br />
<br />
#register a new host<br />
oat_cert -h $OAT_SERVER_IP<br />
oat_host -a -h $OAT_SERVER_IP "<br />
{\"HostName\":\"$OAT_CLIENT_HOST\",\"IPAddress\":\"$OAT_CLIENT_IP\",\"Port\":\"9999\",\"BIOS_Name\":\"$bios\",\"BIOS_Version\":\"$bios_ver\",\"BIOS_Oem\":\"$oem_manu\",\"VMM_Name\":\"$vmm\",\"VMM_Version\":\"$vmm_ver\",\"VMM_OSName\":\"$os\",\"VMM_OSVersion\":\"$os_ver\",\"Email\":\"\",\"AddOn_Connection_String\":\"\",\"Description\":\"\"}"<br />
<br />
==Limitations and Future Work==<br />
<br />
1) Hot Add/Remove of PCIe devices are not supported. A machine reboot is<br />
necessary to obtain fresh measurements and re-attestation.<br />
<br />
2) On detecting that a bare metal instance does not meet trust measurements,<br />
we shall log it. In the future, we shall introduce a Ceilometer alert<br />
event to be consumed by the cloud administrator, perhaps needing follow-up with<br />
the prior tenant. Additionally there is a cleaning step that will address<br />
reflashing BIOS and Option ROMS.<br />
Until reflashed, the untrusted bare metal node will not be allocated to any<br />
tenant.<br />
<br />
3) Blue Pill<br />
When the hardware virtualization support is enabled without a hypervisor<br />
running, the machine is open to launch a Blue Pill style attack. Unfortunately<br />
OEM vendors do not provide the capability to disable Intel TXT or its<br />
equivalents and those that tried to support the same insisted on establishing<br />
physical presence. The reasoning here is the dynamic control feature itself<br />
could pose a vulnerability. Our goal is unaffected by the Blue Pill aspect<br />
because we are concerned strictly with establishing that a machine prior to<br />
hand-off to a tenant is clean, free of rootkits and malware. Should the tenant<br />
seek to install a rootkit, that is in their purview. Once the machine is<br />
released back to the cloud, our workflow will detect and erase the same.<br />
<br />
This said, no claims of trust or re-attestation of a bare metal machine are<br />
possible post boot time. In the Horizon dashboard re-attest action<br />
will not be provided. Node boot time and trust status at boot time will<br />
be displayed.<br />
<br />
==References==<br />
1. http://sourceforge.net/projects/tboot/<br />
<br />
2. https://github.com/OpenAttestation/OpenAttestation<br />
<br />
3. http://en.wikipedia.org/wiki/Trusted_Platform_Module<br />
<br />
4. http://en.wikipedia.org/wiki/Trusted_Execution_Technology<br />
<br />
5. http://docs.openstack.org/admin-guide-cloud/content/trusted-compute-pools.html</div>Tan Linhttps://wiki.openstack.org/w/index.php?title=Bare-metal-trust&diff=87212Bare-metal-trust2015-08-03T10:58:41Z<p>Tan Lin: /* References */</p>
<hr />
<div>==Problem description==<br />
While hypervisors and virtual machines are a common paradigm in the Cloud, heavy compute users seek Bare Metal (BM) to eliminate the performance overhead <br />
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.<br />
<br />
==Proposed solution==<br />
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<br />
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<br />
called TBOOT[1].<br />
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<br />
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<br />
testing is provided by an Open Attestation service, OAT[2]. Additional details in references.<br />
<br />
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.<br />
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<br />
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.<br />
<br />
'''Result:'''<br />
<br />
An OAT client using the customized image verifies the trust state and passes the value to Ironic. The related Horizon blueprint [12] addresses displaying<br />
the trust status of a bare metal node on boot. <br />
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.<br />
<br />
==Work flow==<br />
Note BIOS re-flash and automatic enable TXT will not be available soon.<br />
<br />
1. Manual work to prepare trusted boot<br />
(enable TXT, VT-x, VT-d, take ownership of the TPM)<br />
2. Enable trusted boot for Ironic<br />
http://docs.openstack.org/developer/ironic/deploy/install-guide.html#Trusted-boot-with-partition-image<br />
3. Deploy a trusted boot node<br />
(Boot a customized image with OAT-Client using trusted boot)<br />
(Passing the OAT server URL for attestation)<br />
4. Attestation<br />
(Polls the result from the OAT-Server)<br />
If trusted:<br />
Nodes are available and Jump to 5<br />
5. Deploying<br />
Boot guest image using trusted boot<br />
6. Tenant releases node<br />
<br />
7. Jump to 3<br />
<br />
==How to pass OAT-Server URL==<br />
This can be done via boot instance with user-data, here is a sample about the user-data:<br />
<br />
#!/bin/bash -v<br />
modprobe tpm_tis<br />
modprobe tpm<br />
#OAT-Sever's info<br />
OAT_SERVER_IP=10.239.48.127<br />
OAT_SERVER_USER=admin<br />
OAT_SERVER_PASSWD=p2<br />
<br />
#Node's IP<br />
DEV=eth1<br />
dhclient $DEV<br />
OAT_CLIENT_IP=$(ip addr show dev $DEV | grep ' inet '| awk '{print $2}'|cut -c -12)<br />
OAT_CLIENT_HOST=$OAT_CLIENT_IP<br />
<br />
#Node's info<br />
bios=NewMLE1<br />
bios_ver=v123<br />
oem_manu=OEM1<br />
vmm=NewMLE2<br />
vmm_ver=v123<br />
os=OS1<br />
os_ver=v1<br />
<br />
#Init OAT-Client<br />
iptables -A INPUT -p tcp --dport 8181 -j ACCEPT<br />
iptables -A INPUT -p tcp --dport 8080 -j ACCEPT<br />
iptables -A INPUT -p tcp --dport 9999 -j ACCEPT<br />
iptables -A INPUT -p tcp --dport 9998 -j ACCEPT<br />
/usr/bin/tagent setup <<EOF<br />
$OAT_SERVER_IP \<br />
<br />
$OAT_SERVER_USER<br />
$OAT_SERVER_PASSWD<br />
EOF<br />
<br />
#register a new host<br />
oat_cert -h $OAT_SERVER_IP<br />
oat_host -a -h $OAT_SERVER_IP "<br />
{\"HostName\":\"$OAT_CLIENT_HOST\",\"IPAddress\":\"$OAT_CLIENT_IP\",\"Port\":\"9999\",\"BIOS_Name\":\"$bios\",\"BIOS_Version\":\"$bios_ver\",\"BIOS_Oem\":\"$oem_manu\",\"VMM_Name\":\"$vmm\",\"VMM_Version\":\"$vmm_ver\",\"VMM_OSName\":\"$os\",\"VMM_OSVersion\":\"$os_ver\",\"Email\":\"\",\"AddOn_Connection_String\":\"\",\"Description\":\"\"}"<br />
<br />
==Limitations and Future Work==<br />
<br />
1) Hot Add/Remove of PCIe devices are not supported. A machine reboot is<br />
necessary to obtain fresh measurements and re-attestation.<br />
<br />
2) On detecting that a bare metal instance does not meet trust measurements,<br />
we shall log it. In the future, we shall introduce a Ceilometer alert<br />
event to be consumed by the cloud administrator, perhaps needing follow-up with<br />
the prior tenant. Additionally there is a cleaning step that will address<br />
reflashing BIOS and Option ROMS.<br />
Until reflashed, the untrusted bare metal node will not be allocated to any<br />
tenant.<br />
<br />
3) Blue Pill<br />
When the hardware virtualization support is enabled without a hypervisor<br />
running, the machine is open to launch a Blue Pill style attack. Unfortunately<br />
OEM vendors do not provide the capability to disable Intel TXT or its<br />
equivalents and those that tried to support the same insisted on establishing<br />
physical presence. The reasoning here is the dynamic control feature itself<br />
could pose a vulnerability. Our goal is unaffected by the Blue Pill aspect<br />
because we are concerned strictly with establishing that a machine prior to<br />
hand-off to a tenant is clean, free of rootkits and malware. Should the tenant<br />
seek to install a rootkit, that is in their purview. Once the machine is<br />
released back to the cloud, our workflow will detect and erase the same.<br />
<br />
This said, no claims of trust or re-attestation of a bare metal machine are<br />
possible post boot time. In the Horizon dashboard re-attest action<br />
will not be provided. Node boot time and trust status at boot time will<br />
be displayed.<br />
<br />
==References==<br />
1. http://sourceforge.net/projects/tboot/<br />
<br />
2. https://github.com/OpenAttestation/OpenAttestation<br />
<br />
3. http://en.wikipedia.org/wiki/Trusted_Platform_Module<br />
<br />
4. http://en.wikipedia.org/wiki/Trusted_Execution_Technology<br />
<br />
5. http://docs.openstack.org/admin-guide-cloud/content/trusted-compute-pools.html</div>Tan Linhttps://wiki.openstack.org/w/index.php?title=Bare-metal-trust&diff=87211Bare-metal-trust2015-08-03T10:57:08Z<p>Tan Lin: </p>
<hr />
<div>==Problem description==<br />
While hypervisors and virtual machines are a common paradigm in the Cloud, heavy compute users seek Bare Metal (BM) to eliminate the performance overhead <br />
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.<br />
<br />
==Proposed solution==<br />
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<br />
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<br />
called TBOOT[1].<br />
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<br />
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<br />
testing is provided by an Open Attestation service, OAT[2]. Additional details in references.<br />
<br />
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.<br />
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<br />
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.<br />
<br />
'''Result:'''<br />
<br />
An OAT client using the customized image verifies the trust state and passes the value to Ironic. The related Horizon blueprint [12] addresses displaying<br />
the trust status of a bare metal node on boot. <br />
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.<br />
<br />
==Work flow==<br />
Note BIOS re-flash and automatic enable TXT will not be available soon.<br />
<br />
1. Manual work to prepare trusted boot<br />
(enable TXT, VT-x, VT-d, take ownership of the TPM)<br />
2. Enable trusted boot for Ironic<br />
http://docs.openstack.org/developer/ironic/deploy/install-guide.html#Trusted-boot-with-partition-image<br />
3. Deploy a trusted boot node<br />
(Boot a customized image with OAT-Client using trusted boot)<br />
(Passing the OAT server URL for attestation)<br />
4. Attestation<br />
(Polls the result from the OAT-Server)<br />
If trusted:<br />
Nodes are available and Jump to 5<br />
5. Deploying<br />
Boot guest image using trusted boot<br />
6. Tenant releases node<br />
<br />
7. Jump to 3<br />
<br />
==How to pass OAT-Server URL==<br />
This can be done via boot instance with user-data, here is a sample about the user-data:<br />
<br />
#!/bin/bash -v<br />
modprobe tpm_tis<br />
modprobe tpm<br />
#OAT-Sever's info<br />
OAT_SERVER_IP=10.239.48.127<br />
OAT_SERVER_USER=admin<br />
OAT_SERVER_PASSWD=p2<br />
<br />
#Node's IP<br />
DEV=eth1<br />
dhclient $DEV<br />
OAT_CLIENT_IP=$(ip addr show dev $DEV | grep ' inet '| awk '{print $2}'|cut -c -12)<br />
OAT_CLIENT_HOST=$OAT_CLIENT_IP<br />
<br />
#Node's info<br />
bios=NewMLE1<br />
bios_ver=v123<br />
oem_manu=OEM1<br />
vmm=NewMLE2<br />
vmm_ver=v123<br />
os=OS1<br />
os_ver=v1<br />
<br />
#Init OAT-Client<br />
iptables -A INPUT -p tcp --dport 8181 -j ACCEPT<br />
iptables -A INPUT -p tcp --dport 8080 -j ACCEPT<br />
iptables -A INPUT -p tcp --dport 9999 -j ACCEPT<br />
iptables -A INPUT -p tcp --dport 9998 -j ACCEPT<br />
/usr/bin/tagent setup <<EOF<br />
$OAT_SERVER_IP \<br />
<br />
$OAT_SERVER_USER<br />
$OAT_SERVER_PASSWD<br />
EOF<br />
<br />
#register a new host<br />
oat_cert -h $OAT_SERVER_IP<br />
oat_host -a -h $OAT_SERVER_IP "<br />
{\"HostName\":\"$OAT_CLIENT_HOST\",\"IPAddress\":\"$OAT_CLIENT_IP\",\"Port\":\"9999\",\"BIOS_Name\":\"$bios\",\"BIOS_Version\":\"$bios_ver\",\"BIOS_Oem\":\"$oem_manu\",\"VMM_Name\":\"$vmm\",\"VMM_Version\":\"$vmm_ver\",\"VMM_OSName\":\"$os\",\"VMM_OSVersion\":\"$os_ver\",\"Email\":\"\",\"AddOn_Connection_String\":\"\",\"Description\":\"\"}"<br />
<br />
==Limitations and Future Work==<br />
<br />
1) Hot Add/Remove of PCIe devices are not supported. A machine reboot is<br />
necessary to obtain fresh measurements and re-attestation.<br />
<br />
2) On detecting that a bare metal instance does not meet trust measurements,<br />
we shall log it. In the future, we shall introduce a Ceilometer alert<br />
event to be consumed by the cloud administrator, perhaps needing follow-up with<br />
the prior tenant. Additionally there is a cleaning step that will address<br />
reflashing BIOS and Option ROMS.<br />
Until reflashed, the untrusted bare metal node will not be allocated to any<br />
tenant.<br />
<br />
3) Blue Pill<br />
When the hardware virtualization support is enabled without a hypervisor<br />
running, the machine is open to launch a Blue Pill style attack. Unfortunately<br />
OEM vendors do not provide the capability to disable Intel TXT or its<br />
equivalents and those that tried to support the same insisted on establishing<br />
physical presence. The reasoning here is the dynamic control feature itself<br />
could pose a vulnerability. Our goal is unaffected by the Blue Pill aspect<br />
because we are concerned strictly with establishing that a machine prior to<br />
hand-off to a tenant is clean, free of rootkits and malware. Should the tenant<br />
seek to install a rootkit, that is in their purview. Once the machine is<br />
released back to the cloud, our workflow will detect and erase the same.<br />
<br />
This said, no claims of trust or re-attestation of a bare metal machine are<br />
possible post boot time. In the Horizon dashboard re-attest action<br />
will not be provided. Node boot time and trust status at boot time will<br />
be displayed.<br />
<br />
==References==<br />
1. http://sourceforge.net/projects/tboot/ <br />
2. https://github.com/OpenAttestation/OpenAttestation <br />
3. http://en.wikipedia.org/wiki/Trusted_Platform_Module <br />
4. http://en.wikipedia.org/wiki/Trusted_Execution_Technology <br />
5. https://review.openstack.org/#/c/135228/ <br />
6. http://docs.openstack.org/admin-guide-cloud/content/trusted-compute-pools.html</div>Tan Linhttps://wiki.openstack.org/w/index.php?title=Bare-metal-trust&diff=87210Bare-metal-trust2015-08-03T10:55:24Z<p>Tan Lin: /* How to pass OAT-Server URL */</p>
<hr />
<div>==Problem description==<br />
While hypervisors and virtual machines are a common paradigm in the Cloud, heavy compute users seek Bare Metal (BM) to eliminate the performance overhead <br />
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.<br />
<br />
==Proposed solution==<br />
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<br />
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<br />
called TBOOT[1].<br />
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<br />
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<br />
testing is provided by an Open Attestation service, OAT[2]. Additional details in references.<br />
<br />
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.<br />
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<br />
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.<br />
<br />
'''Result:'''<br />
<br />
An OAT client using the customized image verifies the trust state and passes the value to Ironic. The related Horizon blueprint [12] addresses displaying<br />
the trust status of a bare metal node on boot. <br />
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.<br />
<br />
==Work flow==<br />
Note BIOS re-flash and automatic enable TXT will not be available soon.<br />
<br />
1. Manual work to prepare trusted boot<br />
(enable TXT, VT-x, VT-d, take ownership of the TPM)<br />
2. Enable trusted boot for Ironic<br />
http://docs.openstack.org/developer/ironic/deploy/install-guide.html#Trusted-boot-with-partition-image<br />
3. Deploy a trusted boot node<br />
(Boot a customized image with OAT-Client using trusted boot)<br />
(Passing the OAT server URL for attestation)<br />
4. Attestation<br />
(Polls the result from the OAT-Server)<br />
If trusted:<br />
Nodes are available and Jump to 5<br />
5. Deploying<br />
Boot guest image using trusted boot<br />
6. Tenant releases node<br />
<br />
7. Jump to 3<br />
<br />
==How to pass OAT-Server URL==<br />
This can be done via boot instance with user-data, here is a sample about the user-data:<br />
<br />
#!/bin/bash -v<br />
modprobe tpm_tis<br />
modprobe tpm<br />
#OAT-Sever's info<br />
OAT_SERVER_IP=10.239.48.127<br />
OAT_SERVER_USER=admin<br />
OAT_SERVER_PASSWD=p2<br />
<br />
#Node's IP<br />
DEV=eth1<br />
dhclient $DEV<br />
OAT_CLIENT_IP=$(ip addr show dev $DEV | grep ' inet '| awk '{print $2}'|cut -c -12)<br />
OAT_CLIENT_HOST=$OAT_CLIENT_IP<br />
<br />
#Node's info<br />
bios=NewMLE1<br />
bios_ver=v123<br />
oem_manu=OEM1<br />
vmm=NewMLE2<br />
vmm_ver=v123<br />
os=OS1<br />
os_ver=v1<br />
<br />
#Init OAT-Client<br />
iptables -A INPUT -p tcp --dport 8181 -j ACCEPT<br />
iptables -A INPUT -p tcp --dport 8080 -j ACCEPT<br />
iptables -A INPUT -p tcp --dport 9999 -j ACCEPT<br />
iptables -A INPUT -p tcp --dport 9998 -j ACCEPT<br />
/usr/bin/tagent setup <<EOF<br />
$OAT_SERVER_IP \<br />
<br />
$OAT_SERVER_USER<br />
$OAT_SERVER_PASSWD<br />
EOF<br />
<br />
#register a new host<br />
oat_cert -h $OAT_SERVER_IP<br />
oat_host -a -h $OAT_SERVER_IP "<br />
{\"HostName\":\"$OAT_CLIENT_HOST\",\"IPAddress\":\"$OAT_CLIENT_IP\",\"Port\":\"9999\",\"BIOS_Name\":\"$bios\",\"BIOS_Version\":\"$bios_ver\",\"BIOS_Oem\":\"$oem_manu\",\"VMM_Name\":\"$vmm\",\"VMM_Version\":\"$vmm_ver\",\"VMM_OSName\":\"$os\",\"VMM_OSVersion\":\"$os_ver\",\"Email\":\"\",\"AddOn_Connection_String\":\"\",\"Description\":\"\"}"<br />
<br />
==Limitations and Future Work==<br />
<br />
1) Hot Add/Remove of PCIe devices are not supported. A machine reboot is<br />
necessary to obtain fresh measurements and re-attestation.<br />
<br />
2) On detecting that a bare metal instance does not meet trust measurements,<br />
we shall log it. In the future, we shall introduce a Ceilometer alert<br />
event to be consumed by the cloud administrator, perhaps needing follow-up with<br />
the prior tenant. Additionally there is a cleaning step that will address<br />
reflashing BIOS and Option ROMS.<br />
Until reflashed, the untrusted bare metal node will not be allocated to any<br />
tenant.<br />
<br />
3) Blue Pill<br />
When the hardware virtualization support is enabled without a hypervisor<br />
running, the machine is open to launch a Blue Pill style attack. Unfortunately<br />
OEM vendors do not provide the capability to disable Intel TXT or its<br />
equivalents and those that tried to support the same insisted on establishing<br />
physical presence. The reasoning here is the dynamic control feature itself<br />
could pose a vulnerability. Our goal is unaffected by the Blue Pill aspect<br />
because we are concerned strictly with establishing that a machine prior to<br />
hand-off to a tenant is clean, free of rootkits and malware. Should the tenant<br />
seek to install a rootkit, that is in their purview. Once the machine is<br />
released back to the cloud, our workflow will detect and erase the same.<br />
<br />
This said, no claims of trust or re-attestation of a bare metal machine are<br />
possible post boot time. In the Horizon dashboard re-attest action<br />
will not be provided. Node boot time and trust status at boot time will<br />
be displayed.</div>Tan Linhttps://wiki.openstack.org/w/index.php?title=Bare-metal-trust&diff=87209Bare-metal-trust2015-08-03T10:49:12Z<p>Tan Lin: /* How this work */</p>
<hr />
<div>==Problem description==<br />
While hypervisors and virtual machines are a common paradigm in the Cloud, heavy compute users seek Bare Metal (BM) to eliminate the performance overhead <br />
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.<br />
<br />
==Proposed solution==<br />
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<br />
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<br />
called TBOOT[1].<br />
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<br />
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<br />
testing is provided by an Open Attestation service, OAT[2]. Additional details in references.<br />
<br />
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.<br />
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<br />
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.<br />
<br />
'''Result:'''<br />
<br />
An OAT client using the customized image verifies the trust state and passes the value to Ironic. The related Horizon blueprint [12] addresses displaying<br />
the trust status of a bare metal node on boot. <br />
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.<br />
<br />
==Work flow==<br />
Note BIOS re-flash and automatic enable TXT will not be available soon.<br />
<br />
1. Manual work to prepare trusted boot<br />
(enable TXT, VT-x, VT-d, take ownership of the TPM)<br />
2. Enable trusted boot for Ironic<br />
http://docs.openstack.org/developer/ironic/deploy/install-guide.html#Trusted-boot-with-partition-image<br />
3. Deploy a trusted boot node<br />
(Boot a customized image with OAT-Client using trusted boot)<br />
(Passing the OAT server URL for attestation)<br />
4. Attestation<br />
(Polls the result from the OAT-Server)<br />
If trusted:<br />
Nodes are available and Jump to 5<br />
5. Deploying<br />
Boot guest image using trusted boot<br />
6. Tenant releases node<br />
<br />
7. Jump to 3<br />
<br />
==How to pass OAT-Server URL==<br />
This can be done via boot instance with user-data, here is a sample about the user-data:<br />
<br />
#!/bin/bash -v<br />
modprobe tpm_tis<br />
modprobe tpm<br />
<br />
DEV=eth1<br />
dhclient $DEV<br />
OAT_SERVER_IP=10.239.48.127<br />
OAT_SERVER_USER=admin<br />
OAT_SERVER_PASSWD=p2<br />
<br />
OAT_CLIENT_IP=$(ip addr show dev $DEV | grep ' inet '| awk '{print $2}'|cut -c -12)<br />
OAT_CLIENT_HOST=$OAT_CLIENT_IP<br />
<br />
bios=NewMLE1<br />
bios_ver=v123<br />
oem_manu=OEM1<br />
vmm=NewMLE2<br />
vmm_ver=v123<br />
os=OS1<br />
os_ver=v1<br />
<br />
iptables -A INPUT -p tcp --dport 8181 -j ACCEPT<br />
iptables -A INPUT -p tcp --dport 8080 -j ACCEPT<br />
iptables -A INPUT -p tcp --dport 9999 -j ACCEPT<br />
iptables -A INPUT -p tcp --dport 9998 -j ACCEPT<br />
/usr/bin/tagent setup <<EOF<br />
$OAT_SERVER_IP<br />
<br />
$OAT_SERVER_USER<br />
$OAT_SERVER_PASSWD<br />
EOF<br />
<br />
#register a new host<br />
oat_cert -h $OAT_SERVER_IP<br />
oat_host -a -h $OAT_SERVER_IP "{\"HostName\":\"$OAT_CLIENT_HOST\",\"IPAddress\":\"$OAT_CLIENT_IP\",\"Port\":\"9999\",\"BIOS_Name\":\"$bios\",\"BIOS_Version\":\"$bios_ver\",\"BIOS_Oem\":\"$oem_manu\",\"VMM_Name\":\"$vmm\",\"VMM_Version\":\"$vmm_ver\",\"VMM_OSName\":\"$os\",\"VMM_OSVersion\":\"$os_ver\",\"Email\":\"\",\"AddOn_Connection_String\":\"\",\"Description\":\"\"}"<br />
<br />
==Limitations and Future Work==<br />
<br />
1) Hot Add/Remove of PCIe devices are not supported. A machine reboot is<br />
necessary to obtain fresh measurements and re-attestation.<br />
<br />
2) On detecting that a bare metal instance does not meet trust measurements,<br />
we shall log it. In the future, we shall introduce a Ceilometer alert<br />
event to be consumed by the cloud administrator, perhaps needing follow-up with<br />
the prior tenant. Additionally there is a cleaning step that will address<br />
reflashing BIOS and Option ROMS.<br />
Until reflashed, the untrusted bare metal node will not be allocated to any<br />
tenant.<br />
<br />
3) Blue Pill<br />
When the hardware virtualization support is enabled without a hypervisor<br />
running, the machine is open to launch a Blue Pill style attack. Unfortunately<br />
OEM vendors do not provide the capability to disable Intel TXT or its<br />
equivalents and those that tried to support the same insisted on establishing<br />
physical presence. The reasoning here is the dynamic control feature itself<br />
could pose a vulnerability. Our goal is unaffected by the Blue Pill aspect<br />
because we are concerned strictly with establishing that a machine prior to<br />
hand-off to a tenant is clean, free of rootkits and malware. Should the tenant<br />
seek to install a rootkit, that is in their purview. Once the machine is<br />
released back to the cloud, our workflow will detect and erase the same.<br />
<br />
This said, no claims of trust or re-attestation of a bare metal machine are<br />
possible post boot time. In the Horizon dashboard re-attest action<br />
will not be provided. Node boot time and trust status at boot time will<br />
be displayed.</div>Tan Linhttps://wiki.openstack.org/w/index.php?title=Bare-metal-trust&diff=87208Bare-metal-trust2015-08-03T10:42:10Z<p>Tan Lin: /* Work flow */</p>
<hr />
<div>==Problem description==<br />
While hypervisors and virtual machines are a common paradigm in the Cloud, heavy compute users seek Bare Metal (BM) to eliminate the performance overhead <br />
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.<br />
<br />
==Proposed solution==<br />
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<br />
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<br />
called TBOOT[1].<br />
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<br />
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<br />
testing is provided by an Open Attestation service, OAT[2]. Additional details in references.<br />
<br />
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.<br />
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<br />
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.<br />
<br />
'''Result:'''<br />
<br />
An OAT client using the customized image verifies the trust state and passes the value to Ironic. The related Horizon blueprint [12] addresses displaying<br />
the trust status of a bare metal node on boot. <br />
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.<br />
<br />
==Work flow==<br />
Note BIOS re-flash and automatic enable TXT will not be available soon.<br />
<br />
1. Manual work to prepare trusted boot<br />
(enable TXT, VT-x, VT-d, take ownership of the TPM)<br />
2. Enable trusted boot for Ironic<br />
http://docs.openstack.org/developer/ironic/deploy/install-guide.html#Trusted-boot-with-partition-image<br />
3. Deploy a trusted boot node<br />
(Boot a customized image with OAT-Client using trusted boot)<br />
(Passing the OAT server URL for attestation)<br />
4. Attestation<br />
(Polls the result from the OAT-Server)<br />
If trusted:<br />
Nodes are available and Jump to 5<br />
5. Deploying<br />
Boot guest image using trusted boot<br />
6. Tenant releases node<br />
<br />
7. Jump to 3<br />
<br />
==How this work==<br />
The solution includes two parts, measure and verify:<br />
<br />
1.0 MEASURE<br />
<br />
1.1 Enable TXT in BIOS (Outside of Ironic, Workflow step 1)<br />
This is a prerequisite. We need at least three reboots to enable TPM and TXT.<br />
This should be done manually for now, as it is OEM vendor-specific.<br />
Some scripts may also be available at a later date to handle this aspect<br />
for some OEMs/hardware vendors.<br />
<br />
1.2. Using Trusted Boot (Workflow step 2)<br />
Leverage TBOOT to generate the PCRs values during trusted boot.<br />
Platform Configuration Registers (PCRs) are protected registers provided by<br />
the TPM to store measurement.<br />
<br />
2.0 VERIFY (Outside of Ironic, Workflow step 3)<br />
<br />
2.1 Create customized images<br />
Create a customized image with OAT-Client installed.<br />
OpenAttestation (OAT) is a Remote Attestation solution. It includes several<br />
OAT-Clients and one OAT-Server.<br />
OAT-Client should be installed on each bare metal node to interact with<br />
the TPM. The OAT-Server has a whitelist to verify the PCRs values from<br />
the OAT-Client.<br />
<br />
2.2 Register Nodes<br />
This action happens when every node becomes active.<br />
In order to securely pass PCRs values to OAT-Server, OAT-Client has to<br />
download OAT-Server's certificates and register itself in OAT-Server's DB.<br />
The OAT-Client will register the node into OAT-Server with one of known<br />
good values in the whitelist according to its hardware info. Then the<br />
OAT-Client will compare the node's real PCR values with the whitelist value<br />
and return the result.<br />
<br />
==Limitations and Future Work==<br />
<br />
1) Hot Add/Remove of PCIe devices are not supported. A machine reboot is<br />
necessary to obtain fresh measurements and re-attestation.<br />
<br />
2) On detecting that a bare metal instance does not meet trust measurements,<br />
we shall log it. In the future, we shall introduce a Ceilometer alert<br />
event to be consumed by the cloud administrator, perhaps needing follow-up with<br />
the prior tenant. Additionally there is a cleaning step that will address<br />
reflashing BIOS and Option ROMS.<br />
Until reflashed, the untrusted bare metal node will not be allocated to any<br />
tenant.<br />
<br />
3) Blue Pill<br />
When the hardware virtualization support is enabled without a hypervisor<br />
running, the machine is open to launch a Blue Pill style attack. Unfortunately<br />
OEM vendors do not provide the capability to disable Intel TXT or its<br />
equivalents and those that tried to support the same insisted on establishing<br />
physical presence. The reasoning here is the dynamic control feature itself<br />
could pose a vulnerability. Our goal is unaffected by the Blue Pill aspect<br />
because we are concerned strictly with establishing that a machine prior to<br />
hand-off to a tenant is clean, free of rootkits and malware. Should the tenant<br />
seek to install a rootkit, that is in their purview. Once the machine is<br />
released back to the cloud, our workflow will detect and erase the same.<br />
<br />
This said, no claims of trust or re-attestation of a bare metal machine are<br />
possible post boot time. In the Horizon dashboard re-attest action<br />
will not be provided. Node boot time and trust status at boot time will<br />
be displayed.</div>Tan Linhttps://wiki.openstack.org/w/index.php?title=Bare-metal-trust&diff=87207Bare-metal-trust2015-08-03T10:41:47Z<p>Tan Lin: /* Work flow */</p>
<hr />
<div>==Problem description==<br />
While hypervisors and virtual machines are a common paradigm in the Cloud, heavy compute users seek Bare Metal (BM) to eliminate the performance overhead <br />
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.<br />
<br />
==Proposed solution==<br />
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<br />
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<br />
called TBOOT[1].<br />
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<br />
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<br />
testing is provided by an Open Attestation service, OAT[2]. Additional details in references.<br />
<br />
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.<br />
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<br />
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.<br />
<br />
'''Result:'''<br />
<br />
An OAT client using the customized image verifies the trust state and passes the value to Ironic. The related Horizon blueprint [12] addresses displaying<br />
the trust status of a bare metal node on boot. <br />
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.<br />
<br />
==Work flow==<br />
Note BIOS re-flash and automatic enable TXT will not be available soon.<br />
<br />
1. Manual work to prepare trusted boot<br />
(enable TXT, VT-x, VT-d, take ownership of the TPM)<br />
2. Enable trusted boot for Ironic<br />
http://docs.openstack.org/developer/ironic/deploy/install-guide.html#Trusted-boot-with-partition-image<br />
3. Deploy a trusted boot node<br />
(Boot a customized image with OAT-Client using trusted boot)<br />
(Passing the OAT server URL for attestation)<br />
4. Attestation<br />
(Polls the result from the OAT-Server)<br />
If trusted:<br />
Nodes are available and Jump to 5<br />
5. Deploying<br />
Boot guest image using trusted boot<br />
6. Tenant releases node<br />
7. Jump to 3<br />
<br />
==How this work==<br />
The solution includes two parts, measure and verify:<br />
<br />
1.0 MEASURE<br />
<br />
1.1 Enable TXT in BIOS (Outside of Ironic, Workflow step 1)<br />
This is a prerequisite. We need at least three reboots to enable TPM and TXT.<br />
This should be done manually for now, as it is OEM vendor-specific.<br />
Some scripts may also be available at a later date to handle this aspect<br />
for some OEMs/hardware vendors.<br />
<br />
1.2. Using Trusted Boot (Workflow step 2)<br />
Leverage TBOOT to generate the PCRs values during trusted boot.<br />
Platform Configuration Registers (PCRs) are protected registers provided by<br />
the TPM to store measurement.<br />
<br />
2.0 VERIFY (Outside of Ironic, Workflow step 3)<br />
<br />
2.1 Create customized images<br />
Create a customized image with OAT-Client installed.<br />
OpenAttestation (OAT) is a Remote Attestation solution. It includes several<br />
OAT-Clients and one OAT-Server.<br />
OAT-Client should be installed on each bare metal node to interact with<br />
the TPM. The OAT-Server has a whitelist to verify the PCRs values from<br />
the OAT-Client.<br />
<br />
2.2 Register Nodes<br />
This action happens when every node becomes active.<br />
In order to securely pass PCRs values to OAT-Server, OAT-Client has to<br />
download OAT-Server's certificates and register itself in OAT-Server's DB.<br />
The OAT-Client will register the node into OAT-Server with one of known<br />
good values in the whitelist according to its hardware info. Then the<br />
OAT-Client will compare the node's real PCR values with the whitelist value<br />
and return the result.<br />
<br />
==Limitations and Future Work==<br />
<br />
1) Hot Add/Remove of PCIe devices are not supported. A machine reboot is<br />
necessary to obtain fresh measurements and re-attestation.<br />
<br />
2) On detecting that a bare metal instance does not meet trust measurements,<br />
we shall log it. In the future, we shall introduce a Ceilometer alert<br />
event to be consumed by the cloud administrator, perhaps needing follow-up with<br />
the prior tenant. Additionally there is a cleaning step that will address<br />
reflashing BIOS and Option ROMS.<br />
Until reflashed, the untrusted bare metal node will not be allocated to any<br />
tenant.<br />
<br />
3) Blue Pill<br />
When the hardware virtualization support is enabled without a hypervisor<br />
running, the machine is open to launch a Blue Pill style attack. Unfortunately<br />
OEM vendors do not provide the capability to disable Intel TXT or its<br />
equivalents and those that tried to support the same insisted on establishing<br />
physical presence. The reasoning here is the dynamic control feature itself<br />
could pose a vulnerability. Our goal is unaffected by the Blue Pill aspect<br />
because we are concerned strictly with establishing that a machine prior to<br />
hand-off to a tenant is clean, free of rootkits and malware. Should the tenant<br />
seek to install a rootkit, that is in their purview. Once the machine is<br />
released back to the cloud, our workflow will detect and erase the same.<br />
<br />
This said, no claims of trust or re-attestation of a bare metal machine are<br />
possible post boot time. In the Horizon dashboard re-attest action<br />
will not be provided. Node boot time and trust status at boot time will<br />
be displayed.</div>Tan Linhttps://wiki.openstack.org/w/index.php?title=Bare-metal-trust&diff=87206Bare-metal-trust2015-08-03T10:27:55Z<p>Tan Lin: </p>
<hr />
<div>==Problem description==<br />
While hypervisors and virtual machines are a common paradigm in the Cloud, heavy compute users seek Bare Metal (BM) to eliminate the performance overhead <br />
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.<br />
<br />
==Proposed solution==<br />
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<br />
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<br />
called TBOOT[1].<br />
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<br />
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<br />
testing is provided by an Open Attestation service, OAT[2]. Additional details in references.<br />
<br />
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.<br />
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<br />
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.<br />
<br />
'''Result:'''<br />
<br />
An OAT client using the customized image verifies the trust state and passes the value to Ironic. The related Horizon blueprint [12] addresses displaying<br />
the trust status of a bare metal node on boot. <br />
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.<br />
<br />
==Work flow==<br />
From node enrollment to allocation and release, the various steps.<br />
Note BIOS re-flash and automatic enable TXT will not be available in this cycle<br />
<br />
1. Manual work to prepare trusted boot (Outside of Ironic)<br />
(enable TXT, VT-x, VT-d, take ownership of the TPM)<br />
2. Start trusted boot<br />
(Boot a customized image with OAT-Client using trusted boot)<br />
(Passing the OAT server URL for attestation)<br />
3. Attestation (Outside of Ironic)<br />
Node sends its PCR values to the OAT-Server for attestation<br />
PCRs(0-7) BIOS/Option ROM related<br />
PCRs(17-22) kernel/Ramdisk related<br />
For bare metal trust we are chiefly concerned with PCRs(0-7)<br />
4. Ironic polls the result from the OAT-Server as part of the cleaning task<br />
If trusted:<br />
Nodes are available and Jump to 5<br />
5. Deploying<br />
Boot guest image using trusted boot<br />
6. Tenant releases node<br />
<br />
7. Jump to 2<br />
<br />
==How this work==<br />
The solution includes two parts, measure and verify:<br />
<br />
1.0 MEASURE<br />
<br />
1.1 Enable TXT in BIOS (Outside of Ironic, Workflow step 1)<br />
This is a prerequisite. We need at least three reboots to enable TPM and TXT.<br />
This should be done manually for now, as it is OEM vendor-specific.<br />
Some scripts may also be available at a later date to handle this aspect<br />
for some OEMs/hardware vendors.<br />
<br />
1.2. Using Trusted Boot (Workflow step 2)<br />
Leverage TBOOT to generate the PCRs values during trusted boot.<br />
Platform Configuration Registers (PCRs) are protected registers provided by<br />
the TPM to store measurement.<br />
<br />
2.0 VERIFY (Outside of Ironic, Workflow step 3)<br />
<br />
2.1 Create customized images<br />
Create a customized image with OAT-Client installed.<br />
OpenAttestation (OAT) is a Remote Attestation solution. It includes several<br />
OAT-Clients and one OAT-Server.<br />
OAT-Client should be installed on each bare metal node to interact with<br />
the TPM. The OAT-Server has a whitelist to verify the PCRs values from<br />
the OAT-Client.<br />
<br />
2.2 Register Nodes<br />
This action happens when every node becomes active.<br />
In order to securely pass PCRs values to OAT-Server, OAT-Client has to<br />
download OAT-Server's certificates and register itself in OAT-Server's DB.<br />
The OAT-Client will register the node into OAT-Server with one of known<br />
good values in the whitelist according to its hardware info. Then the<br />
OAT-Client will compare the node's real PCR values with the whitelist value<br />
and return the result.<br />
<br />
==Limitations and Future Work==<br />
<br />
1) Hot Add/Remove of PCIe devices are not supported. A machine reboot is<br />
necessary to obtain fresh measurements and re-attestation.<br />
<br />
2) On detecting that a bare metal instance does not meet trust measurements,<br />
we shall log it. In the future, we shall introduce a Ceilometer alert<br />
event to be consumed by the cloud administrator, perhaps needing follow-up with<br />
the prior tenant. Additionally there is a cleaning step that will address<br />
reflashing BIOS and Option ROMS.<br />
Until reflashed, the untrusted bare metal node will not be allocated to any<br />
tenant.<br />
<br />
3) Blue Pill<br />
When the hardware virtualization support is enabled without a hypervisor<br />
running, the machine is open to launch a Blue Pill style attack. Unfortunately<br />
OEM vendors do not provide the capability to disable Intel TXT or its<br />
equivalents and those that tried to support the same insisted on establishing<br />
physical presence. The reasoning here is the dynamic control feature itself<br />
could pose a vulnerability. Our goal is unaffected by the Blue Pill aspect<br />
because we are concerned strictly with establishing that a machine prior to<br />
hand-off to a tenant is clean, free of rootkits and malware. Should the tenant<br />
seek to install a rootkit, that is in their purview. Once the machine is<br />
released back to the cloud, our workflow will detect and erase the same.<br />
<br />
This said, no claims of trust or re-attestation of a bare metal machine are<br />
possible post boot time. In the Horizon dashboard re-attest action<br />
will not be provided. Node boot time and trust status at boot time will<br />
be displayed.</div>Tan Linhttps://wiki.openstack.org/w/index.php?title=Bare-metal-trust&diff=87205Bare-metal-trust2015-08-03T10:26:58Z<p>Tan Lin: </p>
<hr />
<div>==Problem description==<br />
While hypervisors and virtual machines are a common paradigm in the Cloud, heavy compute users seek Bare Metal (BM) to eliminate the performance overhead <br />
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.<br />
<br />
==Proposed solution'==<br />
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<br />
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<br />
called TBOOT[1].<br />
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<br />
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<br />
testing is provided by an Open Attestation service, OAT[2]. Additional details in references.<br />
<br />
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.<br />
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<br />
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.<br />
<br />
'''Result:'''<br />
<br />
An OAT client using the customized image verifies the trust state and passes the value to Ironic. The related Horizon blueprint [12] addresses displaying<br />
the trust status of a bare metal node on boot. <br />
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.<br />
<br />
'''Work flow'''<br />
===============================<br />
From node enrollment to allocation and release, the various steps.<br />
Note BIOS re-flash and automatic enable TXT will not be available in this cycle<br />
<br />
1. Manual work to prepare trusted boot (Outside of Ironic)<br />
(enable TXT, VT-x, VT-d, take ownership of the TPM)<br />
2. Start trusted boot<br />
(Boot a customized image with OAT-Client using trusted boot)<br />
(Passing the OAT server URL for attestation)<br />
3. Attestation (Outside of Ironic)<br />
Node sends its PCR values to the OAT-Server for attestation<br />
PCRs(0-7) BIOS/Option ROM related<br />
PCRs(17-22) kernel/Ramdisk related<br />
For bare metal trust we are chiefly concerned with PCRs(0-7)<br />
4. Ironic polls the result from the OAT-Server as part of the cleaning task<br />
If trusted:<br />
Nodes are available and Jump to 5<br />
5. Deploying<br />
Boot guest image using trusted boot<br />
6. Tenant releases node<br />
<br />
7. Jump to 2<br />
<br />
'''How this work'''<br />
===============================<br />
The solution includes two parts, measure and verify:<br />
<br />
1.0 MEASURE<br />
<br />
1.1 Enable TXT in BIOS (Outside of Ironic, Workflow step 1)<br />
This is a prerequisite. We need at least three reboots to enable TPM and TXT.<br />
This should be done manually for now, as it is OEM vendor-specific.<br />
Some scripts may also be available at a later date to handle this aspect<br />
for some OEMs/hardware vendors.<br />
<br />
1.2. Using Trusted Boot (Workflow step 2)<br />
Leverage TBOOT to generate the PCRs values during trusted boot.<br />
Platform Configuration Registers (PCRs) are protected registers provided by<br />
the TPM to store measurement.<br />
<br />
2.0 VERIFY (Outside of Ironic, Workflow step 3)<br />
<br />
2.1 Create customized images<br />
Create a customized image with OAT-Client installed.<br />
OpenAttestation (OAT) is a Remote Attestation solution. It includes several<br />
OAT-Clients and one OAT-Server.<br />
OAT-Client should be installed on each bare metal node to interact with<br />
the TPM. The OAT-Server has a whitelist to verify the PCRs values from<br />
the OAT-Client.<br />
<br />
2.2 Register Nodes<br />
This action happens when every node becomes active.<br />
In order to securely pass PCRs values to OAT-Server, OAT-Client has to<br />
download OAT-Server's certificates and register itself in OAT-Server's DB.<br />
The OAT-Client will register the node into OAT-Server with one of known<br />
good values in the whitelist according to its hardware info. Then the<br />
OAT-Client will compare the node's real PCR values with the whitelist value<br />
and return the result.<br />
<br />
'''Limitations and Future Work'''<br />
===============================<br />
<br />
1) Hot Add/Remove of PCIe devices are not supported. A machine reboot is<br />
necessary to obtain fresh measurements and re-attestation.<br />
<br />
2) On detecting that a bare metal instance does not meet trust measurements,<br />
we shall log it. In the future, we shall introduce a Ceilometer alert<br />
event to be consumed by the cloud administrator, perhaps needing follow-up with<br />
the prior tenant. Additionally there is a cleaning step that will address<br />
reflashing BIOS and Option ROMS.<br />
Until reflashed, the untrusted bare metal node will not be allocated to any<br />
tenant.<br />
<br />
3) Blue Pill<br />
When the hardware virtualization support is enabled without a hypervisor<br />
running, the machine is open to launch a Blue Pill style attack. Unfortunately<br />
OEM vendors do not provide the capability to disable Intel TXT or its<br />
equivalents and those that tried to support the same insisted on establishing<br />
physical presence. The reasoning here is the dynamic control feature itself<br />
could pose a vulnerability. Our goal is unaffected by the Blue Pill aspect<br />
because we are concerned strictly with establishing that a machine prior to<br />
hand-off to a tenant is clean, free of rootkits and malware. Should the tenant<br />
seek to install a rootkit, that is in their purview. Once the machine is<br />
released back to the cloud, our workflow will detect and erase the same.<br />
<br />
This said, no claims of trust or re-attestation of a bare metal machine are<br />
possible post boot time. In the Horizon dashboard re-attest action<br />
will not be provided. Node boot time and trust status at boot time will<br />
be displayed.</div>Tan Linhttps://wiki.openstack.org/w/index.php?title=Bare-metal-trust&diff=87204Bare-metal-trust2015-08-03T08:45:14Z<p>Tan Lin: /* = */</p>
<hr />
<div>'''Problem description'''<br />
===============================<br />
While hypervisors and virtual machines are a common paradigm in the Cloud, heavy compute users seek Bare Metal (BM) to eliminate the performance overhead <br />
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.<br />
<br />
'''Proposed solution'''<br />
===============================<br />
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<br />
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<br />
called TBOOT[1].<br />
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<br />
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<br />
testing is provided by an Open Attestation service, OAT[2]. Additional details in references.<br />
<br />
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.<br />
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<br />
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.<br />
<br />
'''Result:'''<br />
<br />
An OAT client using the customized image verifies the trust state and passes the value to Ironic. The related Horizon blueprint [12] addresses displaying<br />
the trust status of a bare metal node on boot. <br />
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.<br />
<br />
'''Work flow'''<br />
===============================<br />
From node enrollment to allocation and release, the various steps.<br />
Note BIOS re-flash and automatic enable TXT will not be available in this cycle<br />
<br />
1. Manual work to prepare trusted boot (Outside of Ironic)<br />
(enable TXT, VT-x, VT-d, take ownership of the TPM)<br />
2. Start trusted boot<br />
(Boot a customized image with OAT-Client using trusted boot)<br />
(Passing the OAT server URL for attestation)<br />
3. Attestation (Outside of Ironic)<br />
Node sends its PCR values to the OAT-Server for attestation<br />
PCRs(0-7) BIOS/Option ROM related<br />
PCRs(17-22) kernel/Ramdisk related<br />
For bare metal trust we are chiefly concerned with PCRs(0-7)<br />
4. Ironic polls the result from the OAT-Server as part of the cleaning task<br />
If trusted:<br />
Nodes are available and Jump to 5<br />
5. Deploying<br />
Boot guest image using trusted boot<br />
6. Tenant releases node<br />
<br />
7. Jump to 2<br />
<br />
'''How this work'''<br />
===============================<br />
The solution includes two parts, measure and verify:<br />
<br />
1.0 MEASURE<br />
<br />
1.1 Enable TXT in BIOS (Outside of Ironic, Workflow step 1)<br />
This is a prerequisite. We need at least three reboots to enable TPM and TXT.<br />
This should be done manually for now, as it is OEM vendor-specific.<br />
Some scripts may also be available at a later date to handle this aspect<br />
for some OEMs/hardware vendors.<br />
<br />
1.2. Using Trusted Boot (Workflow step 2)<br />
Leverage TBOOT to generate the PCRs values during trusted boot.<br />
Platform Configuration Registers (PCRs) are protected registers provided by<br />
the TPM to store measurement.<br />
<br />
2.0 VERIFY (Outside of Ironic, Workflow step 3)<br />
<br />
2.1 Create customized images<br />
Create a customized image with OAT-Client installed.<br />
OpenAttestation (OAT) is a Remote Attestation solution. It includes several<br />
OAT-Clients and one OAT-Server.<br />
OAT-Client should be installed on each bare metal node to interact with<br />
the TPM. The OAT-Server has a whitelist to verify the PCRs values from<br />
the OAT-Client.<br />
<br />
2.2 Register Nodes<br />
This action happens when every node becomes active.<br />
In order to securely pass PCRs values to OAT-Server, OAT-Client has to<br />
download OAT-Server's certificates and register itself in OAT-Server's DB.<br />
The OAT-Client will register the node into OAT-Server with one of known<br />
good values in the whitelist according to its hardware info. Then the<br />
OAT-Client will compare the node's real PCR values with the whitelist value<br />
and return the result.<br />
<br />
'''Limitations and Future Work'''<br />
===============================<br />
<br />
1) Hot Add/Remove of PCIe devices are not supported. A machine reboot is<br />
necessary to obtain fresh measurements and re-attestation.<br />
<br />
2) On detecting that a bare metal instance does not meet trust measurements,<br />
we shall log it. In the future, we shall introduce a Ceilometer alert<br />
event to be consumed by the cloud administrator, perhaps needing follow-up with<br />
the prior tenant. Additionally there is a cleaning step that will address<br />
reflashing BIOS and Option ROMS.<br />
Until reflashed, the untrusted bare metal node will not be allocated to any<br />
tenant.<br />
<br />
3) Blue Pill<br />
When the hardware virtualization support is enabled without a hypervisor<br />
running, the machine is open to launch a Blue Pill style attack. Unfortunately<br />
OEM vendors do not provide the capability to disable Intel TXT or its<br />
equivalents and those that tried to support the same insisted on establishing<br />
physical presence. The reasoning here is the dynamic control feature itself<br />
could pose a vulnerability. Our goal is unaffected by the Blue Pill aspect<br />
because we are concerned strictly with establishing that a machine prior to<br />
hand-off to a tenant is clean, free of rootkits and malware. Should the tenant<br />
seek to install a rootkit, that is in their purview. Once the machine is<br />
released back to the cloud, our workflow will detect and erase the same.<br />
<br />
This said, no claims of trust or re-attestation of a bare metal machine are<br />
possible post boot time. In the Horizon dashboard re-attest action<br />
will not be provided. Node boot time and trust status at boot time will<br />
be displayed.</div>Tan Linhttps://wiki.openstack.org/w/index.php?title=Bare-metal-trust&diff=87203Bare-metal-trust2015-08-03T08:44:23Z<p>Tan Lin: /* == */</p>
<hr />
<div>'''Problem description'''<br />
===============================<br />
While hypervisors and virtual machines are a common paradigm in the Cloud, heavy compute users seek Bare Metal (BM) to eliminate the performance overhead <br />
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.<br />
<br />
'''Proposed solution'''<br />
===============================<br />
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<br />
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<br />
called TBOOT[1].<br />
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<br />
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<br />
testing is provided by an Open Attestation service, OAT[2]. Additional details in references.<br />
<br />
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.<br />
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<br />
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.<br />
<br />
'''Result:'''<br />
<br />
An OAT client using the customized image verifies the trust state and passes the value to Ironic. The related Horizon blueprint [12] addresses displaying<br />
the trust status of a bare metal node on boot. <br />
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.<br />
<br />
'''Work flow'''<br />
===============================<br />
From node enrollment to allocation and release, the various steps.<br />
Note BIOS re-flash and automatic enable TXT will not be available in this cycle<br />
<br />
1. Manual work to prepare trusted boot (Outside of Ironic)<br />
(enable TXT, VT-x, VT-d, take ownership of the TPM)<br />
2. Start trusted boot<br />
(Boot a customized image with OAT-Client using trusted boot)<br />
(Passing the OAT server URL for attestation)<br />
3. Attestation (Outside of Ironic)<br />
Node sends its PCR values to the OAT-Server for attestation<br />
PCRs(0-7) BIOS/Option ROM related<br />
PCRs(17-22) kernel/Ramdisk related<br />
For bare metal trust we are chiefly concerned with PCRs(0-7)<br />
4. Ironic polls the result from the OAT-Server as part of the cleaning task<br />
If trusted:<br />
Nodes are available and Jump to 5<br />
5. Deploying<br />
Boot guest image using trusted boot<br />
6. Tenant releases node<br />
<br />
7. Jump to 2<br />
<br />
'''How this work'''<br />
===============================<br />
The solution includes two parts, measure and verify:<br />
<br />
1.0 MEASURE<br />
<br />
1.1 Enable TXT in BIOS (Outside of Ironic, Workflow step 1)<br />
This is a prerequisite. We need at least three reboots to enable TPM and TXT.<br />
This should be done manually for now, as it is OEM vendor-specific.<br />
Some scripts may also be available at a later date to handle this aspect<br />
for some OEMs/hardware vendors.<br />
<br />
1.2. Using Trusted Boot (Workflow step 2)<br />
Leverage TBOOT to generate the PCRs values during trusted boot.<br />
Platform Configuration Registers (PCRs) are protected registers provided by<br />
the TPM to store measurement.<br />
<br />
2.0 VERIFY (Outside of Ironic, Workflow step 3)<br />
<br />
2.1 Create customized images<br />
Create a customized image with OAT-Client installed.<br />
OpenAttestation (OAT) is a Remote Attestation solution. It includes several<br />
OAT-Clients and one OAT-Server.<br />
OAT-Client should be installed on each bare metal node to interact with<br />
the TPM. The OAT-Server has a whitelist to verify the PCRs values from<br />
the OAT-Client.<br />
<br />
2.2 Register Nodes<br />
This action happens when every node becomes active.<br />
In order to securely pass PCRs values to OAT-Server, OAT-Client has to<br />
download OAT-Server's certificates and register itself in OAT-Server's DB.<br />
The OAT-Client will register the node into OAT-Server with one of known<br />
good values in the whitelist according to its hardware info. Then the<br />
OAT-Client will compare the node's real PCR values with the whitelist value<br />
and return the result.<br />
<br />
'''Limitations and Future Work'''<br />
<br />
Limitations and Future Work<br />
1) Hot Add/Remove of PCIe devices are not supported. A machine reboot is<br />
necessary to obtain fresh measurements and re-attestation.<br />
<br />
2) On detecting that a bare metal instance does not meet trust measurements,<br />
we shall log it. In the future, we shall introduce a Ceilometer alert<br />
event to be consumed by the cloud administrator, perhaps needing follow-up with<br />
the prior tenant. Additionally there is a cleaning step that will address<br />
reflashing BIOS and Option ROMS.<br />
Until reflashed, the untrusted bare metal node will not be allocated to any<br />
tenant.<br />
<br />
3) Blue Pill<br />
When the hardware virtualization support is enabled without a hypervisor<br />
running, the machine is open to launch a Blue Pill style attack. Unfortunately<br />
OEM vendors do not provide the capability to disable Intel TXT or its<br />
equivalents and those that tried to support the same insisted on establishing<br />
physical presence. The reasoning here is the dynamic control feature itself<br />
could pose a vulnerability. Our goal is unaffected by the Blue Pill aspect<br />
because we are concerned strictly with establishing that a machine prior to<br />
hand-off to a tenant is clean, free of rootkits and malware. Should the tenant<br />
seek to install a rootkit, that is in their purview. Once the machine is<br />
released back to the cloud, our workflow will detect and erase the same.<br />
<br />
This said, no claims of trust or re-attestation of a bare metal machine are<br />
possible post boot time. In the Horizon dashboard re-attest action<br />
will not be provided. Node boot time and trust status at boot time will<br />
be displayed.</div>Tan Linhttps://wiki.openstack.org/w/index.php?title=Bare-metal-trust&diff=82149Bare-metal-trust2015-05-29T07:19:54Z<p>Tan Lin: </p>
<hr />
<div>'''Problem description'''<br />
===============================<br />
While hypervisors and virtual machines are a common paradigm in the Cloud, heavy compute users seek Bare Metal (BM) to eliminate the performance overhead <br />
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.<br />
<br />
'''Proposed solution'''<br />
===============================<br />
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<br />
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<br />
called TBOOT[1].<br />
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<br />
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<br />
testing is provided by an Open Attestation service, OAT[2]. Additional details in references.<br />
<br />
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.<br />
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<br />
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.<br />
<br />
'''Result:'''<br />
<br />
An OAT client using the customized image verifies the trust state and passes the value to Ironic. The related Horizon blueprint [12] addresses displaying<br />
the trust status of a bare metal node on boot. <br />
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.<br />
<br />
'''Work flow'''<br />
===============================<br />
From node enrollment to allocation and release, the various steps.<br />
Note BIOS re-flash and automatic enable TXT will not be available in this cycle<br />
<br />
1. Manual work to prepare trusted boot (Outside of Ironic)<br />
(enable TXT, VT-x, VT-d, take ownership of the TPM)<br />
2. Start trusted boot<br />
(Boot a customized image with OAT-Client using trusted boot)<br />
(Passing the OAT server URL for attestation)<br />
3. Attestation (Outside of Ironic)<br />
Node sends its PCR values to the OAT-Server for attestation<br />
PCRs(0-7) BIOS/Option ROM related<br />
PCRs(17-22) kernel/Ramdisk related<br />
For bare metal trust we are chiefly concerned with PCRs(0-7)<br />
4. Ironic polls the result from the OAT-Server as part of the cleaning task<br />
If trusted:<br />
Nodes are available and Jump to 5<br />
5. Deploying<br />
Boot guest image using trusted boot<br />
6. Tenant releases node<br />
<br />
7. Jump to 2<br />
<br />
'''How this work'''<br />
===============================<br />
The solution includes two parts, measure and verify:<br />
<br />
1.0 MEASURE<br />
<br />
1.1 Enable TXT in BIOS (Outside of Ironic, Workflow step 1)<br />
This is a prerequisite. We need at least three reboots to enable TPM and TXT.<br />
This should be done manually for now, as it is OEM vendor-specific.<br />
Some scripts may also be available at a later date to handle this aspect<br />
for some OEMs/hardware vendors.<br />
<br />
1.2. Using Trusted Boot (Workflow step 2)<br />
Leverage TBOOT to generate the PCRs values during trusted boot.<br />
Platform Configuration Registers (PCRs) are protected registers provided by<br />
the TPM to store measurement.<br />
<br />
2.0 VERIFY (Outside of Ironic, Workflow step 3)<br />
<br />
2.1 Create customized images<br />
Create a customized image with OAT-Client installed.<br />
OpenAttestation (OAT) is a Remote Attestation solution. It includes several<br />
OAT-Clients and one OAT-Server.<br />
OAT-Client should be installed on each bare metal node to interact with<br />
the TPM. The OAT-Server has a whitelist to verify the PCRs values from<br />
the OAT-Client.<br />
<br />
2.2 Register Nodes<br />
This action happens when every node becomes active.<br />
In order to securely pass PCRs values to OAT-Server, OAT-Client has to<br />
download OAT-Server's certificates and register itself in OAT-Server's DB.<br />
The OAT-Client will register the node into OAT-Server with one of known<br />
good values in the whitelist according to its hardware info. Then the<br />
OAT-Client will compare the node's real PCR values with the whitelist value<br />
and return the result.<br />
<br />
'''Limitations and Future Work'''<br />
<br />
============================================<br />
1) Hot Add/Remove of PCIe devices are not supported. A machine reboot is<br />
necessary to obtain fresh measurements and re-attestation.<br />
<br />
2) On detecting that a bare metal instance does not meet trust measurements,<br />
we shall log it. In the future, we shall introduce a Ceilometer alert<br />
event to be consumed by the cloud administrator, perhaps needing follow-up with<br />
the prior tenant. Additionally there is a cleaning step that will address<br />
reflashing BIOS and Option ROMS.<br />
Until reflashed, the untrusted bare metal node will not be allocated to any<br />
tenant.<br />
<br />
3) Blue Pill<br />
When the hardware virtualization support is enabled without a hypervisor<br />
running, the machine is open to launch a Blue Pill style attack. Unfortunately<br />
OEM vendors do not provide the capability to disable Intel TXT or its<br />
equivalents and those that tried to support the same insisted on establishing<br />
physical presence. The reasoning here is the dynamic control feature itself<br />
could pose a vulnerability. Our goal is unaffected by the Blue Pill aspect<br />
because we are concerned strictly with establishing that a machine prior to<br />
hand-off to a tenant is clean, free of rootkits and malware. Should the tenant<br />
seek to install a rootkit, that is in their purview. Once the machine is<br />
released back to the cloud, our workflow will detect and erase the same.<br />
<br />
This said, no claims of trust or re-attestation of a bare metal machine are<br />
possible post boot time. In the Horizon dashboard re-attest action<br />
will not be provided. Node boot time and trust status at boot time will<br />
be displayed.</div>Tan Linhttps://wiki.openstack.org/w/index.php?title=Bare-metal-trust&diff=82148Bare-metal-trust2015-05-29T07:18:40Z<p>Tan Lin: </p>
<hr />
<div>'''Problem description'''<br />
===============================<br />
While hypervisors and virtual machines are a common paradigm in the Cloud, heavy compute users seek Bare Metal (BM) to eliminate the performance overhead <br />
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.<br />
<br />
'''Proposed solution'''<br />
===============================<br />
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<br />
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<br />
called TBOOT[1].<br />
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<br />
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<br />
testing is provided by an Open Attestation service, OAT[2]. Additional details in references.<br />
<br />
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.<br />
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<br />
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.<br />
<br />
'''Result:'''<br />
<br />
An OAT client using the customized image verifies the trust state and passes the value to Ironic. The related Horizon blueprint [12] addresses displaying<br />
the trust status of a bare metal node on boot. <br />
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.<br />
<br />
'''Work flow'''<br />
===============================<br />
From node enrollment to allocation and release, the various steps.<br />
Note BIOS re-flash and automatic enable TXT will not be available in this cycle<br />
<br />
1. Manual work to prepare trusted boot (Outside of Ironic)<br />
(enable TXT, VT-x, VT-d, take ownership of the TPM)<br />
2. Start trusted boot<br />
(Boot a customized image with OAT-Client using trusted boot)<br />
(Passing the OAT server URL for attestation)<br />
3. Attestation (Outside of Ironic)<br />
Node sends its PCR values to the OAT-Server for attestation<br />
PCRs(0-7) BIOS/Option ROM related<br />
PCRs(17-22) kernel/Ramdisk related<br />
For bare metal trust we are chiefly concerned with PCRs(0-7)<br />
4. Ironic polls the result from the OAT-Server as part of the cleaning task<br />
If trusted:<br />
Nodes are available and Jump to 5<br />
5. Deploying<br />
Boot guest image using trusted boot<br />
6. Tenant releases node<br />
<br />
7. Jump to 2<br />
<br />
'''How this work'''<br />
---------------<br />
The solution includes two parts, measure and verify:<br />
<br />
1.0 MEASURE<br />
<br />
1.1 Enable TXT in BIOS (Outside of Ironic, Workflow step 1)<br />
This is a prerequisite. We need at least three reboots to enable TPM and TXT.<br />
This should be done manually for now, as it is OEM vendor-specific.<br />
Some scripts may also be available at a later date to handle this aspect<br />
for some OEMs/hardware vendors.<br />
<br />
1.2. Using Trusted Boot (Workflow step 2)<br />
Leverage TBOOT to generate the PCRs values during trusted boot.<br />
Platform Configuration Registers (PCRs) are protected registers provided by<br />
the TPM to store measurement.<br />
<br />
2.0 VERIFY (Outside of Ironic, Workflow step 3)<br />
<br />
2.1 Create customized images<br />
Create a customized image with OAT-Client installed.<br />
OpenAttestation (OAT) is a Remote Attestation solution. It includes several<br />
OAT-Clients and one OAT-Server.<br />
OAT-Client should be installed on each bare metal node to interact with<br />
the TPM. The OAT-Server has a whitelist to verify the PCRs values from<br />
the OAT-Client.<br />
<br />
2.2 Register Nodes<br />
This action happens when every node becomes active.<br />
In order to securely pass PCRs values to OAT-Server, OAT-Client has to<br />
download OAT-Server's certificates and register itself in OAT-Server's DB.<br />
The OAT-Client will register the node into OAT-Server with one of known<br />
good values in the whitelist according to its hardware info. Then the<br />
OAT-Client will compare the node's real PCR values with the whitelist value<br />
and return the result.<br />
<br />
'''Limitations and Future Work'''<br />
<br />
============================================<br />
1) Hot Add/Remove of PCIe devices are not supported. A machine reboot is<br />
necessary to obtain fresh measurements and re-attestation.<br />
<br />
2) On detecting that a bare metal instance does not meet trust measurements,<br />
we shall log it. In the future, we shall introduce a Ceilometer alert<br />
event to be consumed by the cloud administrator, perhaps needing follow-up with<br />
the prior tenant. Additionally there is a cleaning step that will address<br />
reflashing BIOS and Option ROMS.<br />
Until reflashed, the untrusted bare metal node will not be allocated to any<br />
tenant.<br />
<br />
3) Blue Pill<br />
When the hardware virtualization support is enabled without a hypervisor<br />
running, the machine is open to launch a Blue Pill style attack. Unfortunately<br />
OEM vendors do not provide the capability to disable Intel TXT or its<br />
equivalents and those that tried to support the same insisted on establishing<br />
physical presence. The reasoning here is the dynamic control feature itself<br />
could pose a vulnerability. Our goal is unaffected by the Blue Pill aspect<br />
because we are concerned strictly with establishing that a machine prior to<br />
hand-off to a tenant is clean, free of rootkits and malware. Should the tenant<br />
seek to install a rootkit, that is in their purview. Once the machine is<br />
released back to the cloud, our workflow will detect and erase the same.<br />
<br />
This said, no claims of trust or re-attestation of a bare metal machine are<br />
possible post boot time. In the Horizon dashboard re-attest action<br />
will not be provided. Node boot time and trust status at boot time will<br />
be displayed.</div>Tan Linhttps://wiki.openstack.org/w/index.php?title=Bare-metal-trust&diff=82147Bare-metal-trust2015-05-29T07:10:37Z<p>Tan Lin: /* = */</p>
<hr />
<div>'''Problem description'''<br />
===============================<br />
While hypervisors and virtual machines are a common paradigm in the Cloud, heavy compute users seek Bare Metal (BM) to eliminate the performance overhead <br />
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.<br />
<br />
'''Proposed solution'''<br />
===============================<br />
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<br />
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<br />
called TBOOT[1].<br />
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<br />
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<br />
testing is provided by an Open Attestation service, OAT[2]. Additional details in references.<br />
<br />
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.<br />
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<br />
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.<br />
<br />
'''Result:'''<br />
<br />
An OAT client using the customized image verifies the trust state and passes the value to Ironic. The related Horizon blueprint [12] addresses displaying<br />
the trust status of a bare metal node on boot. <br />
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.<br />
<br />
'''Work flow'''<br />
===============================<br />
From node enrollment to allocation and release, the various steps.<br />
Note BIOS re-flash and automatic enable TXT will not be available in this cycle<br />
<br />
1. Manual work to prepare trusted boot (Outside of Ironic)<br />
(enable TXT, VT-x, VT-d, take ownership of the TPM)<br />
2. Start trusted boot<br />
(Boot a customized image with OAT-Client using trusted boot)<br />
(Passing the OAT server URL for attestation)<br />
3. Attestation (Outside of Ironic)<br />
Node sends its PCR values to the OAT-Server for attestation<br />
PCRs(0-7) BIOS/Option ROM related<br />
PCRs(17-22) kernel/Ramdisk related<br />
For bare metal trust we are chiefly concerned with PCRs(0-7)<br />
4. Ironic polls the result from the OAT-Server as part of the cleaning task<br />
If trusted:<br />
Nodes are available and Jump to 5<br />
5. Deploying<br />
Boot guest image using trusted boot<br />
6. Tenant releases node<br />
<br />
7. Jump to 2<br />
<br />
'''How this work''<br />
---------------<br />
The solution includes two parts, measure and verify:<br />
<br />
1.0 MEASURE<br />
<br />
1.1 Enable TXT in BIOS (Outside of Ironic, Workflow step 1)<br />
This is a prerequisite. We need at least three reboots to enable TPM and TXT.<br />
This should be done manually for now, as it is OEM vendor-specific.<br />
Some scripts may also be available at a later date to handle this aspect<br />
for some OEMs/hardware vendors.<br />
<br />
1.2. Using Trusted Boot (Workflow step 2)<br />
Leverage TBOOT to generate the PCRs values during trusted boot.<br />
Platform Configuration Registers (PCRs) are protected registers provided by<br />
the TPM to store measurement.<br />
<br />
2.0 VERIFY (Outside of Ironic, Workflow step 3)<br />
<br />
2.1 Create customized images<br />
Create a customized image with OAT-Client installed.<br />
OpenAttestation (OAT) is a Remote Attestation solution. It includes several<br />
OAT-Clients and one OAT-Server.<br />
OAT-Client should be installed on each bare metal node to interact with<br />
the TPM. The OAT-Server has a whitelist to verify the PCRs values from<br />
the OAT-Client.<br />
<br />
2.2 Register Nodes<br />
This action happens when every node becomes active.<br />
In order to securely pass PCRs values to OAT-Server, OAT-Client has to<br />
download OAT-Server's certificates and register itself in OAT-Server's DB.<br />
The OAT-Client will register the node into OAT-Server with one of known<br />
good values in the whitelist according to its hardware info. Then the<br />
OAT-Client will compare the node's real PCR values with the whitelist value<br />
and return the result.<br />
<br />
'''Limitations and Future Work'''<br />
<br />
============================================<br />
1) Hot Add/Remove of PCIe devices are not supported. A machine reboot is<br />
necessary to obtain fresh measurements and re-attestation.<br />
<br />
2) On detecting that a bare metal instance does not meet trust measurements,<br />
we shall log it. In the future, we shall introduce a Ceilometer alert<br />
event to be consumed by the cloud administrator, perhaps needing follow-up with<br />
the prior tenant. Additionally there is a cleaning step that will address<br />
reflashing BIOS and Option ROMS.<br />
Until reflashed, the untrusted bare metal node will not be allocated to any<br />
tenant.<br />
<br />
3) Blue Pill<br />
When the hardware virtualization support is enabled without a hypervisor<br />
running, the machine is open to launch a Blue Pill style attack. Unfortunately<br />
OEM vendors do not provide the capability to disable Intel TXT or its<br />
equivalents and those that tried to support the same insisted on establishing<br />
physical presence. The reasoning here is the dynamic control feature itself<br />
could pose a vulnerability. Our goal is unaffected by the Blue Pill aspect<br />
because we are concerned strictly with establishing that a machine prior to<br />
hand-off to a tenant is clean, free of rootkits and malware. Should the tenant<br />
seek to install a rootkit, that is in their purview. Once the machine is<br />
released back to the cloud, our workflow will detect and erase the same.<br />
<br />
This said, no claims of trust or re-attestation of a bare metal machine are<br />
possible post boot time. In the Horizon dashboard re-attest action<br />
will not be provided. Node boot time and trust status at boot time will<br />
be displayed.</div>Tan Linhttps://wiki.openstack.org/w/index.php?title=Bare-metal-trust&diff=82145Bare-metal-trust2015-05-29T06:56:35Z<p>Tan Lin: </p>
<hr />
<div>'''Problem description'''<br />
===============================<br />
While hypervisors and virtual machines are a common paradigm in the Cloud, heavy compute users seek Bare Metal (BM) to eliminate the performance overhead <br />
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.<br />
<br />
'''Proposed solution'''<br />
===============================<br />
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<br />
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<br />
called TBOOT[1].<br />
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<br />
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<br />
testing is provided by an Open Attestation service, OAT[2]. Additional details in references.<br />
<br />
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.<br />
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<br />
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.<br />
<br />
'''Result:'''<br />
<br />
An OAT client using the customized image verifies the trust state and passes the value to Ironic. The related Horizon blueprint [12] addresses displaying<br />
the trust status of a bare metal node on boot. <br />
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.<br />
<br />
'''Work flow'''<br />
===============================<br />
From node enrollment to allocation and release, the various steps.<br />
Note BIOS re-flash and automatic enable TXT will not be available in this cycle<br />
<br />
1. Manual work to prepare trusted boot (Outside of Ironic)<br />
(enable TXT, VT-x, VT-d, take ownership of the TPM)<br />
2. Cleaning task to start trusted bot<br />
(Boot a customized image with OAT-Client using trusted boot)<br />
(Passing the OAT server URL for attestation)<br />
3. Attestation (Outside of Ironic)<br />
Node sends its PCR values to the OAT-Server for attestation<br />
PCRs(0-7) BIOS/Option ROM related<br />
PCRs(17-22) kernel/Ramdisk related<br />
For bare metal trust we are chiefly concerned with PCRs(0-7)<br />
4. Ironic polls the result from the OAT-Server as part of the cleaning task<br />
If trusted:<br />
Nodes are available and Jump to 6<br />
5. Cleaning task to reflash Node<br />
6. Deploying<br />
Boot guest image using trusted boot<br />
7. Attestation by user (Outside of Ironic and optional)<br />
<br />
8. Tenant releases node<br />
<br />
9. Jump to 2<br />
<br />
'''Detail workflow'''<br />
---------------<br />
The solution includes two parts, measure and verify:<br />
<br />
1.0 MEASURE<br />
<br />
1.1 Enable TXT in BIOS (Outside of Ironic, Workflow step 1)<br />
This is a prerequisite. We need at least three reboots to enable TPM and TXT.<br />
This should be done manually for now, as it is OEM vendor-specific.<br />
Some scripts may also be available at a later date to handle this aspect<br />
for some OEMs/hardware vendors.<br />
<br />
1.2. Using Trusted Boot (Workflow step 2 and 6)<br />
Leverage TBOOT to generate the PCRs values during trusted boot.<br />
Platform Configuration Registers (PCRs) are protected registers provided by<br />
the TPM to store measurement.<br />
<br />
2.0 VERIFY (Outside of Ironic, Workflow step 3 and 7)<br />
<br />
2.1 Create customized images<br />
Create a customized image with OAT-Client installed.<br />
OpenAttestation (OAT) is a Remote Attestation solution. It includes several<br />
OAT-Clients and one OAT-Server.<br />
OAT-Client should be installed on each bare metal node to interact with<br />
the TPM. The OAT-Server has a whitelist to verify the PCRs values from<br />
the OAT-Client.<br />
<br />
2.2 Register Nodes<br />
This action happens when every node becomes active.<br />
In order to securely pass PCRs values to OAT-Server, OAT-Client has to<br />
download OAT-Server's certificates and register itself in OAT-Server's DB.<br />
Pass the OAT-Server IP address to the node to configure the OAT-Client<br />
and start the service, the node will call the OAT-Server to compare the<br />
PCR values from the TPM with whitelist on the OAT-Server.<br />
<br />
'''Limitations and Future Work'''<br />
============================================<br />
1) Hot Add/Remove of PCIe devices are not supported. A machine reboot is<br />
necessary to obtain fresh measurements and re-attestation.<br />
<br />
2) On detecting that a bare metal instance does not meet trust measurements,<br />
we shall log it. In the future, we shall introduce a Ceilometer alert<br />
event to be consumed by the cloud administrator, perhaps needing follow-up with<br />
the prior tenant. Additionally there is a cleaning step that will address<br />
reflashing BIOS and Option ROMS.<br />
Until reflashed, the untrusted bare metal node will not be allocated to any<br />
tenant.<br />
<br />
3) Blue Pill<br />
When the hardware virtualization support is enabled without a hypervisor<br />
running, the machine is open to launch a Blue Pill style attack. Unfortunately<br />
OEM vendors do not provide the capability to disable Intel TXT or its<br />
equivalents and those that tried to support the same insisted on establishing<br />
physical presence. The reasoning here is the dynamic control feature itself<br />
could pose a vulnerability. Our goal is unaffected by the Blue Pill aspect<br />
because we are concerned strictly with establishing that a machine prior to<br />
hand-off to a tenant is clean, free of rootkits and malware. Should the tenant<br />
seek to install a rootkit, that is in their purview. Once the machine is<br />
released back to the cloud, our workflow will detect and erase the same.<br />
<br />
This said, no claims of trust or re-attestation of a bare metal machine are<br />
possible post boot time. In the Horizon dashboard re-attest action<br />
will not be provided. Node boot time and trust status at boot time will<br />
be displayed.</div>Tan Linhttps://wiki.openstack.org/w/index.php?title=Bare-metal-trust&diff=82144Bare-metal-trust2015-05-29T06:35:55Z<p>Tan Lin: /* = */</p>
<hr />
<div>'''Problem description'''<br />
===============================<br />
While hypervisors and virtual machines are a common paradigm in the Cloud, heavy compute users seek Bare Metal (BM) to eliminate the performance overhead <br />
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.<br />
<br />
'''Proposed solution'''<br />
===============================<br />
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<br />
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<br />
called TBOOT[1].<br />
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<br />
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<br />
testing is provided by an Open Attestation service, OAT[2]. Additional details in references.<br />
<br />
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.<br />
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<br />
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.<br />
<br />
'''Result:'''<br />
<br />
An OAT client using the customized image verifies the trust state and passes the value to Ironic. The related Horizon blueprint [12] addresses displaying<br />
the trust status of a bare metal node on boot. <br />
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.<br />
<br />
'''Work flow'''<br />
===============================<br />
From node enrollment to allocation and release, the various steps.<br />
Note BIOS re-flash and automatic enable TXT will not be available in this cycle<br />
<br />
1. Manual work to prepare trusted boot (Outside of Ironic)<br />
(enable TXT, VT-x, VT-d, take ownership of the TPM)<br />
2. Cleaning task to start trusted bot<br />
(Boot a customized image with OAT-Client using trusted boot)<br />
(Passing the OAT server URL for attestation)<br />
3. Attestation (Outside of Ironic)<br />
Node sends its PCR values to the OAT-Server for attestation<br />
PCRs(0-7) BIOS/Option ROM related<br />
PCRs(17-22) kernel/Ramdisk related<br />
For bare metal trust we are chiefly concerned with PCRs(0-7)<br />
4. Ironic polls the result from the OAT-Server as part of the cleaning task<br />
If trusted:<br />
Nodes are available and Jump to 6<br />
5. Cleaning task to reflash Node<br />
6. Deploying<br />
Boot guest image using trusted boot<br />
7. Attestation by user (Outside of Ironic and optional)<br />
<br />
8. Tenant releases node<br />
<br />
9. Jump to 2<br />
<br />
'''Limitations and Future Work'''<br />
============================================<br />
1) Hot Add/Remove of PCIe devices are not supported. A machine reboot is<br />
necessary to obtain fresh measurements and re-attestation.<br />
<br />
2) On detecting that a bare metal instance does not meet trust measurements,<br />
we shall log it. In the future, we shall introduce a Ceilometer alert<br />
event to be consumed by the cloud administrator, perhaps needing follow-up with<br />
the prior tenant. Additionally there is a cleaning step that will address<br />
reflashing BIOS and Option ROMS.<br />
Until reflashed, the untrusted bare metal node will not be allocated to any<br />
tenant.<br />
<br />
3) Blue Pill<br />
When the hardware virtualization support is enabled without a hypervisor<br />
running, the machine is open to launch a Blue Pill style attack. Unfortunately<br />
OEM vendors do not provide the capability to disable Intel TXT or its<br />
equivalents and those that tried to support the same insisted on establishing<br />
physical presence. The reasoning here is the dynamic control feature itself<br />
could pose a vulnerability. Our goal is unaffected by the Blue Pill aspect<br />
because we are concerned strictly with establishing that a machine prior to<br />
hand-off to a tenant is clean, free of rootkits and malware. Should the tenant<br />
seek to install a rootkit, that is in their purview. Once the machine is<br />
released back to the cloud, our workflow will detect and erase the same.<br />
<br />
This said, no claims of trust or re-attestation of a bare metal machine are<br />
possible post boot time. In the Horizon dashboard re-attest action<br />
will not be provided. Node boot time and trust status at boot time will<br />
be displayed.</div>Tan Linhttps://wiki.openstack.org/w/index.php?title=Bare-metal-trust&diff=82143Bare-metal-trust2015-05-29T06:34:41Z<p>Tan Lin: </p>
<hr />
<div>'''Problem description'''<br />
===============================<br />
While hypervisors and virtual machines are a common paradigm in the Cloud, heavy compute users seek Bare Metal (BM) to eliminate the performance overhead <br />
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.<br />
<br />
'''Proposed solution'''<br />
===============================<br />
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<br />
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<br />
called TBOOT[1].<br />
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<br />
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<br />
testing is provided by an Open Attestation service, OAT[2]. Additional details in references.<br />
<br />
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.<br />
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<br />
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.<br />
<br />
'''Result:'''<br />
<br />
An OAT client using the customized image verifies the trust state and passes the value to Ironic. The related Horizon blueprint [12] addresses displaying<br />
the trust status of a bare metal node on boot. <br />
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.<br />
<br />
'''Work flow'''<br />
===============================<br />
From node enrollment to allocation and release, the various steps.<br />
Note BIOS re-flash and automatic enable TXT will not be available in this cycle<br />
<br />
1. Manual work to prepare trusted boot (Outside of Ironic)<br />
(enable TXT, VT-x, VT-d, take ownership of the TPM)<br />
2. Cleaning task to start trusted bot<br />
(Boot a customized image with OAT-Client using trusted boot)<br />
(Passing the OAT server URL for attestation)<br />
3. Attestation (Outside of Ironic)<br />
Node sends its PCR values to the OAT-Server for attestation<br />
PCRs(0-7) BIOS/Option ROM related<br />
PCRs(17-22) kernel/Ramdisk related<br />
For bare metal trust we are chiefly concerned with PCRs(0-7)<br />
4. Ironic polls the result from the OAT-Server as part of the cleaning task<br />
If trusted:<br />
Nodes are available and Jump to 6<br />
5. Cleaning task to reflash Node<br />
6. Deploying<br />
Boot guest image using trusted boot<br />
7. Attestation by user (Outside of Ironic and optional)<br />
<br />
8. Tenant releases node<br />
<br />
9. Jump to 2<br />
<br />
'''Limitations and Future Work'''<br />
===============================<br />
1) Hot Add/Remove of PCIe devices are not supported. A machine reboot is<br />
necessary to obtain fresh measurements and re-attestation.<br />
<br />
2) On detecting that a bare metal instance does not meet trust measurements,<br />
we shall log it. In the future, we shall introduce a Ceilometer alert<br />
event to be consumed by the cloud administrator, perhaps needing follow-up with<br />
the prior tenant. Additionally there is a cleaning step that will address<br />
reflashing BIOS and Option ROMS.<br />
Until reflashed, the untrusted bare metal node will not be allocated to any<br />
tenant.<br />
<br />
3) Blue Pill<br />
When the hardware virtualization support is enabled without a hypervisor<br />
running, the machine is open to launch a Blue Pill style attack. Unfortunately<br />
OEM vendors do not provide the capability to disable Intel TXT or its<br />
equivalents and those that tried to support the same insisted on establishing<br />
physical presence. The reasoning here is the dynamic control feature itself<br />
could pose a vulnerability. Our goal is unaffected by the Blue Pill aspect<br />
because we are concerned strictly with establishing that a machine prior to<br />
hand-off to a tenant is clean, free of rootkits and malware. Should the tenant<br />
seek to install a rootkit, that is in their purview. Once the machine is<br />
released back to the cloud, our workflow will detect and erase the same.<br />
<br />
This said, no claims of trust or re-attestation of a bare metal machine are<br />
possible post boot time. In the Horizon dashboard re-attest action<br />
will not be provided. Node boot time and trust status at boot time will<br />
be displayed.</div>Tan Linhttps://wiki.openstack.org/w/index.php?title=Bare-metal-trust&diff=82142Bare-metal-trust2015-05-29T06:32:32Z<p>Tan Lin: /* = */</p>
<hr />
<div>'''Problem description'''<br />
===============================<br />
While hypervisors and virtual machines are a common paradigm in the Cloud, heavy compute users seek Bare Metal (BM) to eliminate the performance overhead <br />
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.<br />
<br />
'''Proposed solution'''<br />
===============================<br />
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<br />
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<br />
called TBOOT[1].<br />
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<br />
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<br />
testing is provided by an Open Attestation service, OAT[2]. Additional details in references.<br />
<br />
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.<br />
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<br />
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.<br />
<br />
'''Result:'''<br />
<br />
An OAT client using the customized image verifies the trust state and passes the value to Ironic. The related Horizon blueprint [12] addresses displaying<br />
the trust status of a bare metal node on boot. <br />
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.<br />
<br />
'''Work flow'''<br />
===============================<br />
From node enrollment to allocation and release, the various steps.<br />
Note BIOS re-flash and automatic enable TXT will not be available in this cycle<br />
<br />
1. Manual work to prepare trusted boot (Outside of Ironic)<br />
(enable TXT, VT-x, VT-d, take ownership of the TPM)<br />
2. Cleaning task to start trusted bot<br />
(Boot a customized image with OAT-Client using trusted boot)<br />
(Passing the OAT server URL for attestation)<br />
3. Attestation (Outside of Ironic)<br />
Node sends its PCR values to the OAT-Server for attestation<br />
PCRs(0-7) BIOS/Option ROM related<br />
PCRs(17-22) kernel/Ramdisk related<br />
For bare metal trust we are chiefly concerned with PCRs(0-7)<br />
4. Ironic polls the result from the OAT-Server as part of the cleaning task<br />
If trusted:<br />
Nodes are available and Jump to 6<br />
5. Cleaning task to reflash Node<br />
6. Deploying<br />
Boot guest image using trusted boot<br />
7. Attestation by user (Outside of Ironic and optional)<br />
<br />
8. Tenant releases node<br />
<br />
9. Jump to 2</div>Tan Linhttps://wiki.openstack.org/w/index.php?title=Bare-metal-trust&diff=82141Bare-metal-trust2015-05-29T06:31:55Z<p>Tan Lin: </p>
<hr />
<div>'''Problem description'''<br />
===============================<br />
While hypervisors and virtual machines are a common paradigm in the Cloud, heavy compute users seek Bare Metal (BM) to eliminate the performance overhead <br />
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.<br />
<br />
'''Proposed solution'''<br />
===============================<br />
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<br />
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<br />
called TBOOT[1].<br />
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<br />
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<br />
testing is provided by an Open Attestation service, OAT[2]. Additional details in references.<br />
<br />
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.<br />
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<br />
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.<br />
<br />
'''Result:'''<br />
<br />
An OAT client using the customized image verifies the trust state and passes the value to Ironic. The related Horizon blueprint [12] addresses displaying<br />
the trust status of a bare metal node on boot. <br />
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.<br />
<br />
'''Work flow'''<br />
===============================<br />
From node enrollment to allocation and release, the various steps.<br />
Note BIOS re-flash and automatic enable TXT will not be available in this cycle<br />
<br />
1. Manual work to prepare trusted boot (Outside of Ironic)<br />
(enable TXT, VT-x, VT-d, take ownership of the TPM)<br />
2. Cleaning task to start trusted bot<br />
(Boot a customized image with OAT-Client using trusted boot)<br />
(Passing the OAT server URL for attestation)<br />
3. Attestation (Outside of Ironic)<br />
Node sends its PCR values to the OAT-Server for attestation<br />
PCRs(0-7) BIOS/Option ROM related<br />
PCRs(17-22) kernel/Ramdisk related<br />
For bare metal trust we are chiefly concerned with PCRs(0-7)<br />
4. Ironic polls the result from the OAT-Server as part of the cleaning task<br />
If trusted:<br />
Nodes are available and Jump to 6<br />
5. Cleaning task to reflash Node<br />
6. Deploying<br />
Boot guest image using trusted boot<br />
7. Attestation by user (Outside of Ironic and optional)<br />
8. Tenant releases node<br />
9. Jump to 2</div>Tan Linhttps://wiki.openstack.org/w/index.php?title=Bare-metal-trust&diff=82140Bare-metal-trust2015-05-29T06:30:02Z<p>Tan Lin: </p>
<hr />
<div>'''Problem description'''<br />
===============================<br />
While hypervisors and virtual machines are a common paradigm in the Cloud, heavy compute users seek Bare Metal (BM) to eliminate the performance overhead <br />
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.<br />
<br />
'''Proposed solution'''<br />
===============================<br />
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<br />
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<br />
called TBOOT[1].<br />
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<br />
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<br />
testing is provided by an Open Attestation service, OAT[2]. Additional details in references.<br />
<br />
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.<br />
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<br />
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.<br />
<br />
'''Result:'''<br />
<br />
An OAT client using the customized image verifies the trust state and passes the value to Ironic. The related Horizon blueprint [12] addresses displaying<br />
the trust status of a bare metal node on boot. <br />
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.<br />
<br />
Work flow<br />
===============================<br />
From node enrollment to allocation and release, the various steps.<br />
Note BIOS re-flash and automatic enable TXT will not be available in this cycle<br />
<br />
1. Manual work to prepare trusted boot (Outside of Ironic)<br />
(enable TXT, VT-x, VT-d, take ownership of the TPM)<br />
2. Cleaning task to start trusted bot<br />
(Boot a customized image with OAT-Client using trusted boot)<br />
(Passing the OAT server URL for attestation)<br />
3. Attestation (Outside of Ironic)<br />
Node sends its PCR values to the OAT-Server for attestation<br />
PCRs(0-7) BIOS/Option ROM related<br />
PCRs(17-22) kernel/Ramdisk related<br />
For bare metal trust we are chiefly concerned with PCRs(0-7)<br />
4. Ironic polls the result from the OAT-Server as part of the cleaning task<br />
If trusted:<br />
Nodes are available and Jump to 6<br />
5. Cleaning task to reflash Node<br />
6. Deploying<br />
Boot guest image using trusted boot<br />
7. Attestation by user (Outside of Ironic and optional)<br />
8. Tenant releases node<br />
9. Jump to 2</div>Tan Linhttps://wiki.openstack.org/w/index.php?title=Bare-metal-trust&diff=82138Bare-metal-trust2015-05-29T05:48:32Z<p>Tan Lin: </p>
<hr />
<div>'''Problem description'''<br />
===============================<br />
While hypervisors and virtual machines are a common paradigm in the Cloud, heavy compute users seek Bare Metal (BM) to eliminate the performance overhead <br />
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.<br />
<br />
'''Proposed solution'''<br />
===============================<br />
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<br />
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<br />
called TBOOT[1].<br />
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<br />
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<br />
testing is provided by an Open Attestation service, OAT[2]. Additional details in references.<br />
<br />
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.<br />
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<br />
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.<br />
<br />
'''Result:'''<br />
<br />
An OAT client using the customized image verifies the trust state and passes the value to Ironic. The related Horizon blueprint [12] addresses displaying<br />
the trust status of a bare metal node on boot. <br />
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.</div>Tan Linhttps://wiki.openstack.org/w/index.php?title=Bare-metal-trust&diff=82137Bare-metal-trust2015-05-29T05:46:24Z<p>Tan Lin: Created page with "'''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 over..."</p>
<hr />
<div>'''Problem description'''<br />
While hypervisors and virtual machines are a common paradigm in the Cloud, heavy compute users seek Bare Metal (BM) to eliminate the performance overhead <br />
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.<br />
<br />
'''Proposed solution'''<br />
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<br />
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<br />
called TBOOT[1].<br />
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<br />
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<br />
testing is provided by an Open Attestation service, OAT[2]. Additional details in references.<br />
<br />
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.<br />
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<br />
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.<br />
<br />
Result:<br />
<br />
An OAT client using the customized image verifies the trust state and passes the value to Ironic. The related Horizon blueprint [12] addresses displaying<br />
the trust status of a bare metal node on boot. <br />
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.</div>Tan Linhttps://wiki.openstack.org/w/index.php?title=CrossProjectLiaisons&diff=81796CrossProjectLiaisons2015-05-26T06:07:41Z<p>Tan Lin: /* Oslo */</p>
<hr />
<div>Many of our cross-project teams need focused help for communicating with the other project teams. This page lists the people who have volunteered for that work.<br />
<br />
== Oslo ==<br />
<br />
There are now more projects consuming code from the Oslo incubator than we have Oslo contributors. That means we are going to need your help to make these migrations happen. We are asking for one person from each project to serve as a liaison between the project and Oslo, and to assist with integrating changes as we move code out of the incubator into libraries.<br />
<br />
* The liaison should be a core reviewer for the project, but does not need to be the PTL.<br />
* The liaison should be prepared to assist with writing and reviewing patches in their project as libraries are adopted, and with discussions of API changes to the libraries to make them easier to use within the project.<br />
* Liaisons should pay attention to [Oslo] tagged messages on the openstack-dev mailing list.<br />
* It is also useful for liaisons to be able to attend the Oslo team meeting ([[Meetings/Oslo]]) to participate in discussions and raise issues for real-time discussion.<br />
<br />
{| class="wikitable"<br />
|-<br />
! Project !! Liaison !! IRC Handle<br />
|-<br />
| Barbican || Douglas Mendizábal || redrobot<br />
|-<br />
| Ceilometer || Julien Danjou || jd__<br />
|-<br />
| Cinder || Jay Bryant || jungleboyj<br />
|-<br />
| Designate || || <br />
|-<br />
| Glance || Louis Taylor || kragniz<br />
|-<br />
| Heat || Thomas Herve || therve<br />
|-<br />
| Horizon || Akihiro Motoki || amotoki<br />
|-<br />
| Ironic || Lin Tan || lintan<br />
|-<br />
| Keystone || Brant Knudson || bknudson<br />
|-<br />
| Manila || Thomas Bechtold || toabctl<br />
|-<br />
| Neutron || Ihar Hrachyshka || ihrachyshka<br />
|-<br />
| Nova || || <br />
|-<br />
| [[Octavia]] || Michael Johnson || johnsom<br />
|-<br />
| Sahara || Sergey Reshetnyak || sreshetnyak<br />
|-<br />
| Swift || || <br />
|-<br />
| TripleO || Ben Nemec || bnemec<br />
|-<br />
| Trove || Amrith Kumar || amrith<br />
|-<br />
| Zaqar || Flavio Percoco || flaper87<br />
|-<br />
|}<br />
<br />
== Release management ==<br />
<br />
The Release Management Liaison is responsible for communication with the Release Management team, attending the weekly 1:1 syncs in #openstack-relmgr-office, keeping milestone plans up to date, and signing off milestone and release tags. That task has been [[PTL_Guide#Interactions_with_the_Release_team|traditionally filled by the PTL]], but they may now delegate this task if they wish.<br />
<br />
* By default, the liaison will be the PTL.<br />
* The Release Management Liaison is considered a contributor to the Release Cycle Management Program and therefore is allowed to vote in election its PTL.<br />
* The liaison may further delegate work to other subject matter experts<br />
<br />
{| class="wikitable"<br />
|-<br />
! Project !! Liaison !! IRC Handle<br />
|-<br />
| Nova || John Garbutt || johnthetubaguy<br />
|-<br />
| Cinder || Mike Perez || thingee<br />
|-<br />
| Swift || John Dickinson || notmyname<br />
|-<br />
| Neutron || Kyle Mestery || mestery<br />
|-<br />
| Keystone || Morgan Fainberg || morganfainberg<br />
|-<br />
| Horizon || David Lyle || david-lyle<br />
|-<br />
| Glance || Nikhil Komawar || nikhil_k<br />
|-<br />
| Ceilometer || Eoghan Glynn || eglynn <br />
|-<br />
| Heat || Angus Salkeld || asalkeld<br />
|-<br />
| Oslo || Doug Hellmann || dhellmann<br />
|-<br />
| Trove || Nikhil Manchanda || SlickNik<br />
|-<br />
| Sahara || Sergey Lukjanov || SergeyLukjanov<br />
|-<br />
| Ironic || Devananda Van der Veen || devananda<br />
|-<br />
| Zaqar || || <br />
|-<br />
| Designate || || <br />
|-<br />
| Barbican || Douglas Mendizábal || redrobot<br />
|-<br />
| Manila || Ben Swartzlander || bswartz<br />
|}<br />
<br />
== QA ==<br />
<br />
There are now more projects that are being tested by Tempest, and Grenade or a part deployable by Devstack than we have QA contributors. That means we are going to need your help to keep on top of everything. We are asking for one person from each project to serve as a liaison between the project and QA, and to assist with integrating changes as we move forward.<br />
<br />
The liaison should be a core reviewer for the project, but does not need to be the PTL. The liaison should be prepared to assist with writing and reviewing patches that interact with their project, and with discussions of changes to the QA projects to make them easier to use within the project.<br />
<br />
{| class="wikitable"<br />
|-<br />
! Project !! Liaison !! IRC Handle<br />
|-<br />
| Nova || Matt Riedemann || mriedem<br />
|-<br />
| Cinder || || <br />
|-<br />
| Swift || || <br />
|-<br />
| Neutron || Salvatore Orlando || salv-orlando<br />
|-<br />
| Keystone || David Stanek || dstanek<br />
|-<br />
| Horizon || || <br />
|-<br />
| Glance || || <br />
|-<br />
| Ceilometer || Dina Belova || DinaBelova<br />
|-<br />
| Heat || Steve Baker || stevebaker<br />
|-<br />
| Oslo || Davanum Srinivas || dims <br />
|-<br />
| Trove || Nikhil Manchanda and Peter Stachowski || SlickNik and peterstac<br />
|-<br />
| Sahara || Luigi Toscano and Sergey Lukjanov || tosky and SergeyLukjanov<br />
|-<br />
| Ironic || Adam Gandelman || adam_g<br />
|-<br />
| Zaqar || || <br />
|-<br />
| Barbican || Steve Heyman || hockeynut <br />
|-<br />
| Manila || Valeriy Ponomaryov || vponomaryov<br />
|}<br />
<br />
== Documentation ==<br />
<br />
The OpenStack Documentation is centralized on docs.openstack.org but often there's a need for specialty information when reviewing patches or triaging doc bugs. A doc liaison should be available to triage doc bugs when the docs team members don't know enough to triage accurately, and be added to doc reviews that affect your project. You'd be notified through email when you're added either to a doc bug or a doc review. We also would appreciate attendance at the [https://wiki.openstack.org/wiki/Meetings/DocTeamMeeting weekly doc team meeting], We meet weekly in #openstack-meeting every Wednesday at alternating times for different timezones:<br />
<br />
1st Wednesday, 03:00:00 UTC #openstack-meeting (APAC)<br />
<br />
2nd Wednesday, 14:00:00 UTC #openstack-meeting (US)<br />
<br />
3rd Wednesday, 03:00:00 UTC #openstack-meeting (APAC)<br />
<br />
4th Wednesday, 14:00:00 UTC #openstack-meeting (US)<br />
<br />
{| class="wikitable"<br />
|-<br />
! Project !! Liaison !! IRC Handle<br />
|-<br />
| Nova || Joe Gordon or Michael Still || Jog0 or mikal<br />
|-<br />
| Cinder || Mike Perez || thingee <br />
|-<br />
| Swift || Atul Jha or Chuck Thier || koolhead or creight<br />
|-<br />
| Neutron || Edgar Magana || emagana <br />
|-<br />
| Keystone || Steve Martinelli || stevemar<br />
|-<br />
| Horizon || Rob Cresswell || robcresswell<br />
|-<br />
| Glance || Brian Rosmaita || rosmaita<br />
|-<br />
| Ceilometer || Ildiko Vancsa || ildikov<br />
|-<br />
| Heat || Randall Burt || randallburt<br />
|-<br />
| Oslo || Doug Hellmann || dhellmann<br />
|-<br />
| Trove || Laurel Michaels, Matt Griffin || laurelm mattgriffin<br />
|-<br />
| Sahara || Chad Roberts || crobertsrh<br />
|-<br />
| Ironic || Mitsuhiro SHIGEMATSU || pshige<br />
|-<br />
| Zaqar || || <br />
|-<br />
| Barbican || Constanze Kratel || constanze <br />
|-<br />
| Manila || || <br />
|}<br />
<br />
== Stable Branch ==<br />
<br />
The Stable Branch Liaison is responsible for making sure backports are proposed for critical issues in their project, and make sure proposed backports<br />
are reviewed. They are also the contact point for stable branch release managers around point release times.<br />
<br />
* By default, the liaison will be the PTL.<br />
* The Stable Branch Liaison is considered a contributor to the Release Cycle Management Program and therefore is allowed to vote in election its PTL.<br />
* The liaison may further delegate work to other subject matter experts<br />
<br />
{| class="wikitable"<br />
|-<br />
! Project !! Liaison !! IRC Handle<br />
|-<br />
| Ceilometer || Eoghan Glynn || eglynn<br />
|-<br />
| Cinder || Jay Bryant || jungleboyj<br />
|-<br />
| Glance || Erno Kuvaja || jokke_<br />
|-<br />
| Heat || Zane Bitter || zaneb<br />
|-<br />
| Horizon || Matthias Runge || mrunge <br />
|-<br />
| Ironic || Adam Gandelman || adam_g<br />
|-<br />
| Keystone || Dolph Mathews || dolphm<br />
|-<br />
| Neutron || Kyle Mestery (Ihar Hrachyshka?) || mestery (ihrachyshka?)<br />
|-<br />
| Nova || || <br />
|-<br />
| Sahara || Sergey Lukjanov || SergeyLukjanov<br />
|-<br />
| Swift || || <br />
|-<br />
| Trove || Amrith Kumar || amrith<br />
|-<br />
|}<br />
<br />
== Vulnerability management ==<br />
<br />
The [[Vulnerability Management]] Team needs domain specialists to help assessing the impact of reported issues, coordinate the development of patches, review proposed patches and propose backports. The liaison should be familiar with the [[Vulnerability Management]] process and embargo rules, and have a good grasp of security issues in software design.<br />
<br />
* The liaison should be a core reviewer for the project, but does not need to be the PTL.<br />
* By default, the liaison will be the PTL.<br />
* The liaison is the first line of contact for the Vulnerability Management team members<br />
* The liaison is considered a contributor to the Release Cycle Management Program and therefore is allowed to vote in election its PTL<br />
* The liaison may further delegate work to other subject matter experts<br />
* The liaison maintains the members of the $PROJECT-coresec team in Launchpad (which can be given access to embargoed vulnerabilities)<br />
<br />
{| class="wikitable"<br />
|-<br />
! Project !! Liaison !! IRC Handle<br />
|-<br />
| Ceilometer || Lianhao Lu or Gordon Chung || llu/gordc <br />
|-<br />
| Cinder || || <br />
|-<br />
| Glance || Stuart McLaren or Nikhil Komawar || mclaren or nikhil_k <br />
|-<br />
| Heat || Steve Hardy || shardy<br />
|-<br />
| Horizon || Lin Hua Cheng || lhcheng <br />
|-<br />
| Ironic || Jim Rollenhagen || jroll<br />
|-<br />
| Keystone || Dolph Mathews || dolphm<br />
|-<br />
| Neutron || Salvatore Orlando || salv-orlando<br />
|-<br />
| Nova || Michael Still || mikal<br />
|-<br />
| Sahara || Michael McCune or Sergey Lukjanov || elmiko or SergeyLukjanov<br />
|-<br />
| Swift || || <br />
|-<br />
| Trove || Nikhil Manchanda || SlickNik <br />
|-<br />
|}<br />
<br />
== API Working Group ==<br />
<br />
The [[API_Working_Group|API Working Group]] seeks API subject matter experts for each project to communicate plans for API updates, review API guidelines with their project's view in mind, and review the API Working Group guidelines as they are drafted. The liaison should be familiar with the project's REST API design and future planning for changes to it.<br />
<br />
* The liaison should be the PTL or whomever they delegate to be their representative<br />
* The liaison is the first line of contact for the API Working Group team members<br />
* The liaison may further delegate work to other subject matter experts<br />
* The liaison should be aware of and engaged in the API Working Group [[API_Working_Group#Communication|Communication channels]]<br />
* The Nova team has been very explicit about how they will liaise with the API Working Group, see the [[Nova/APIWGLiaisons|Responsibilities of Liaisons]]<br />
<br />
{| class="wikitable"<br />
|-<br />
! Project !! Liaison !! IRC Handle<br />
|-<br />
| Barbican || Douglas Mendizábal || redrobot<br />
|-<br />
| Ceilometer || Chris Dent || cdent<br />
|-<br />
| Cinder || Mike Perez || thingee<br />
|-<br />
| Glance || Stuart McLaren or Nikhil Komawar || mclaren or nikhil_k <br />
|-<br />
| Heat || Ryan Brown || ryansb<br />
|-<br />
| Horizon || Cindy Lu || clu_ <br />
|-<br />
| Ironic || Lucas Alvares Gomes || lucasagomes<br />
|-<br />
| Keystone || Dolph Mathews || dolphm<br />
|-<br />
| Neutron || Salvatore Orlando || salv-orlando <br />
|-<br />
| Nova || Matthew Gilliard and Alex Xu || gilliard and alex_xu <br />
|-<br />
| Sahara || Michael McCune and Sergey Lukjanov || elmiko and SergeyLukjanov<br />
|-<br />
| Swift || John Dickinson || notmyname <br />
|-<br />
| Trove || Peter Stachowski and Amrith Kumar || peterstac and amrith<br />
|-<br />
| MagnetoDB|| Ilya Sviridov || isviridov<br />
|-<br />
|}<br />
<br />
== Logging Working Group ==<br />
<br />
The [[LogWorkingGroup|Log Working Group]] seeks experts for each project to assist with making the logging in projects match the new [http://specs.openstack.org/openstack/openstack-specs/specs/log-guidelines.html Logging Guidelines]<br />
<br />
{| class="wikitable"<br />
|-<br />
! Project !! Liaison !! IRC Handle<br />
|-<br />
| Glance || Erno Kuvaja || jokke_<br />
|-<br />
| Oslo || Doug Hellmann || dhellmann<br />
|-<br />
| Nova || John Garbutt || johnthetubaguy<br />
|-<br />
| Sahara || Nikolay Starodubtsev || Nikolay_St<br />
|}<br />
<br />
== Inter-project Liaisons ==<br />
<br />
In some cases, it is useful to have liaisons between projects. [http://lists.openstack.org/pipermail/openstack-dev/2015-April/062327.html For example, it is useful for the Nova and Neutron projects to have liaisons, because the projects have complex interactions and dependencies.] Ideally, a cross-project effort should have two members, one from each project, to facilitate communication and knowledge transfer.<br />
<br />
{| class="wikitable"<br />
|-<br />
! Projects !! Name !! IRC Handle !! Role<br />
|-<br />
| Nova / Neutron || || ||<br />
|-<br />
| || Sean M. Collins || sc68cal || Neutron liaison for Nova<br />
|-<br />
| || Brent Eagles || beagles || Nova liaison for Neutron<br />
|-<br />
| Nova / Ironic || John Villalovos || ||<br />
|-<br />
| Neutron / Ironic || || ||<br />
|-<br />
| || Sukhdev Kapur || sukhdev || Neutron liaison for Ironic<br />
|-<br />
| || Mitsuhiro SHIGEMATSU and Jim Rollenhagen || pshige and jroll || Ironic liaison for Neutron<br />
|}</div>Tan Linhttps://wiki.openstack.org/w/index.php?title=Ironic/Drivers&diff=75525Ironic/Drivers2015-03-13T02:52:56Z<p>Tan Lin: /* Drivers */</p>
<hr />
<div>== Drivers ==<br />
<br />
Ironic supports pluggable back-end drivers for different types of hardware to enable features specific to unique hardware platforms and leverage divergent capabilities via a common API . This API is divided into three sections: core, common, and vendor. While authors of vendor drivers may break new ground in the designated "vendor_passthru" section of the API, they are strongly encouraged to converge on a common API across vendors. More details may be found under the [http://docs.openstack.org/developer/ironic/dev/architecture.html#drivers system architecture] description.<br />
<br />
Hardware drivers must undergo CI testing so as to ensure their continued functionality. Some drivers will be tested upstream, while many will require third-party CI testing due to the unique nature of their hardware (and the unmanageable complexity were a single team required to maintain a test infrastructure encompassing hardware from many diverse vendors). Guidelines on that testing can be found on the [[Ironic/Testing]] wiki page.<br />
<br />
Out-of-tree drivers are supported by Ironic and may be loaded via python entrypoints.<br />
<br />
The table below describes the CI test coverage of the current set of drivers. Note that drivers are composed of more than one interface (eg, power and deploy). Not all combinations of interfaces are necessarily tested together, but we are striving to get test coverage for each interface in at least one driver. <br />
<br />
<br />
{| class="wikitable"<br />
|-<br />
! Interface Type !! Interface Name !! Test coverage provided by driver name<br />
|-<br />
| deploy || agent || agent_ssh; agent_ipmitool is used in production for Rackspace OnMetal<br />
|-<br />
| deploy || pxe || pxe_ssh<br />
|-<br />
| power || drac || None<br />
|-<br />
| power || ilo || None<br />
|-<br />
| power || ipminative || pxe_ipminative (provided by ibm-xcat-ci)<br />
|-<br />
| power || ipmitool || ** most widely used power driver in production, but lacks upstream CI<br />
|-<br />
| power || seamicro || None<br />
|-<br />
| power || snmp || None<br />
|-<br />
| power || ssh || pxe_ssh<br />
|-<br />
| power || amt|| None<br />
|}<br />
<br />
<br />
Links to graphs of the CI system's current status should be included in the table below, when available.<br />
<br />
{| class="wikitable"<br />
|-<br />
! Driver Name !! Primary Contact Email and IRC handle !! Testing Status<br />
|-<br />
| pxe_ssh || devananda (devananda dot vdv at gmail) || [http://no-carrier.net/~adam/openstack/ironic_gate_status.html tested in the upstream gate]<br />
|-<br />
| pxe_ipminative || linggao (linggao at us dot ibm dot com) / Jarrod Johnson (jjohnson2 at lenovo dot com) || Third-party CI: "ibm-xcat-ci" <xcat@cn.ibm.com><br />
|-<br />
| pxe_ipmitool || devananda (devananda dot vdv at gmail) || used by TripleO, but not CI tested<br />
|-<br />
| agent_ssh || jroll (jim at jimrollenhagen dot com) || [http://no-carrier.net/~adam/openstack/ironic_gate_status.html tested in the upstream gate]<br />
|-<br />
| agent_ipmitool || jroll (jim at jimrollenhagen dot com) || used by Rackspace OnMetal, not CI tested upstream<br />
|-<br />
|}<br />
<br />
== 3rd Party Drivers ==<br />
<br />
iLO drivers: https://wiki.openstack.org/wiki/Ironic/Drivers/iLODrivers</div>Tan Linhttps://wiki.openstack.org/w/index.php?title=Meetings/Ironic&diff=71577Meetings/Ironic2015-01-12T07:16:30Z<p>Tan Lin: /* Agenda for next meeting */</p>
<hr />
<div>= Weekly Ironic Project Team Meeting =<br />
<br />
If you're interested in bare metal deployments within OpenStack, please join our weekly discussion about the [[Ironic|Ironic project]]! Meetings are held in the <code><nowiki>#openstack-meeting-3</nowiki></code> room on <code><nowiki>irc.freenode.net</nowiki></code>, and are chaired by Devananda or Chris Krelle (NobodyCam).<br />
<br />
The Meeting time alternates between '''1700 UTC on Monday''' and '''0500 UTC on Tuesday''', to accomodate contributors from around the world. The next meeting is scheduled for January 6th, 2015 (http://www.timeanddate.com/worldclock/fixedtime.html?iso=20150106T0500). <br />
<br />
NOTE: <span style="color:green">Meeting time is UTC based and may need to be adjusted based on local time zone changes, eg. as a result of daylight savings, which changes on different days in different countries.</span><br><br><br />
<br />
<br />
The meeting format has recently changed. As before, anyone is welcome to add topics to the agenda, however topics should be posted '''at least two (2) days before the meeting''', and should include the IRC handle of the proposer and a link to further information. This gives everyone time to review any material ahead of time so we can use the meeting time for actual discussion.<br />
* Example topic: (devananda) Let's talk about zebras. Reference: http://en.wikipedia.org/wiki/Zebra<br />
<br />
<br />
== Agenda for next meeting ==<br />
<br />
* Announcements<br />
* Review [https://etherpad.openstack.org/p/IronicWhiteBoard subteam status reports] (capped at ten minutes)<br />
* Agenda<br />
** (Nobodycam) Looking for eyes on the "Current" state machine reviews<br />
*** https://review.openstack.org/#/q/status:open+project:openstack/ironic+topic:bp/new-ironic-state-machine,n,z<br />
** (devananda) stable branch maintenance<br />
*** http://lists.openstack.org/pipermail/openstack-dev/2014-December/053366.html<br />
** (JayF) Breaking change for IPA HardwareManager API<br />
*** http://lists.openstack.org/pipermail/openstack-dev/2014-December/053662.html<br />
** (dtantsur) Suggestion to land driver-specific periodic tasks despite parallelization being blocked on oslo.service graduation<br />
*** https://review.openstack.org/#/c/135589/<br />
* Open Discussion<br />
<br />
== Previous meetings ==<br />
<br />
[http://eavesdrop.openstack.org/meetings/ironic/ Logs from previous meetings can be found here.]</div>Tan Lin