Txt Introduction

7,950 views

Published on

This slide is crested and presented by Weiqi Dai, PhD candidate of College of Computer Science, Huazhong University of Science & Technology

Published in: Technology
2 Comments
6 Likes
Statistics
Notes
No Downloads
Views
Total views
7,950
On SlideShare
0
From Embeds
0
Number of Embeds
174
Actions
Shares
0
Downloads
0
Comments
2
Likes
6
Embeds 0
No embeds

No notes for slide

Txt Introduction

  1. 1. Intel ® Trusted Execution Technology <br />1<br />
  2. 2. Static root of trust for measurement<br />Dynamic root of trust for measurement<br />Flicker: Minimal TCB Code Execution<br />Static root of trust for measurement<br />
  3. 3. 3<br />Basic TPM Functions<br />PCRs store integrity measurement chain<br />PCRnew = SHA-1(PCRold||measurement)<br />Remote attestation (PCRs + AIK)<br />Attestation Identity Keys (AIKs) for signing PCRs<br />Attest to value of integrity measurements to remote party<br />Sealed storage (PCRs + SRK)<br />Protected storage + unlock state under a particular integrity measurement (data portability concern)<br />
  4. 4. 4<br />TCG-Style Attestation<br />OS Kernel<br />OS Kernel<br />Apps<br />Apps<br />Module 1<br />Module 1<br />App 1<br />App 1<br />Module 2<br />Module 2<br />App 2<br />App 2<br />TPM<br />conf<br />conf<br />PCRs<br />Boot Loader<br />Boot Loader<br />BIOS<br />BIOS<br />Hardware<br />Software<br />AIK-1<br />
  5. 5. 5<br />TCG-Style Attestation<br />Host platform<br />Challenger<br />
  6. 6. 6<br />TCG-style Attestation的缺点<br />Static root of trust for measurement (reboot)<br />Measures entire system<br />Requires hundreds of integrity measurements just to boot<br />Every host is different<br />firmware versions, drivers, patches, apps, spyware, …<br />TCB includes entire system!<br />Integrity measurements are done at load-time not at run-time<br />Time-of-check-time-of-use (TOCTOU) problem<br />Cannot detect any dynamic attacks!<br />No guarantee of execution<br />A1<br />A2<br />A3<br />Operating System<br />Hardware TPM<br />
  7. 7. 7<br />Example: TCG on Linux<br />Integrity Measurement Architecture (IMA) by IBM<br />Measurement principles<br />Whole system measurements<br />Measure all executable content on-demand<br />Too expensive to measure whole system<br />Content is added dynamically<br />Measure content before execution<br />Only measured content can introduce and measure new content<br />Place as little trust as necessary in measurement system<br />
  8. 8. 8<br />Linux Implementation Overview<br />Use trusted boot to measure BIOS, bootstrap loader, and kernel<br />The kernel keeps a list of measurements for each loaded<br />Executable Scripts (shell, Perl, etc)<br />Shared library Java class files<br />Kernel module …<br />Before a measurement is added to the list, PCR10 is extended with that measurement. Integrity of this in-kernel list is guaranteed by PCR10<br />Verification: Given initial value of PCR10, extend it with each measurement and match result to current PCR10<br />Quote is used to attest to PCRs<br />
  9. 9. 9<br />Linux Bootstrap Stages<br />Operating System<br />/usr/sbin/httpd<br />GRUB<br />Stage2<br />/bin/ls<br />BIOS<br />Bootloader<br />Linux<br />Kernel<br />GRUB<br />Stage1<br />(MBR)<br />ROT<br />GRUB<br />Stage1.5<br />CRTM<br />POST<br />PCR01-07<br />PCR04-05<br />TPM<br />PCR08<br />PCR10<br />Trusted Boot<br />
  10. 10. 10<br />SHA1(Boot Loader)SHA1(Kernel)SHA1(Kernel Module)SHA1(Program)SHA1(Configuration)…<br />h<br />+<br />Digest of Measurements Signed by TPM<br />Analysis<br />TPM<br />KnownHashes<br />Integrity Measurement Architecture (IMA)<br />Network<br />Attesting System<br />Challenging System<br />Properties of Attesting System<br />Measurements<br /> Data<br /> Program<br /> Config File<br /> KernelModule<br /> BootLoader<br /> Kernel<br />(1) Measurement<br />(2) Attestation<br />(3) Verification<br />
  11. 11. 11<br />Linux Modifications<br />Added support to Linux kernel<br />To measure dynamic linker<br />To measure each executable<br />Added support to dynamic linker<br />To measure each shared library<br />Added support to kernel module loader<br />To measure kernel modules<br />Kernel keeps a measurement cache<br />Files are only measured once!<br />Unless modified (opened for writing)<br />
  12. 12. 12<br />Linux Application Measurements<br />cat /proc/tcg/measurements<br />#000: 276249898F406BE176E3D86EDD5A3D20D03EEB11 [remeasure] linuxrc<br />#001: 9F860256709F1CD35037563DCDF798054F878705 [remeasure] nash<br />#002: 4CC52A8F7584A750303CB2A41DEA637917DB0310 [clean] insmod<br />#003: 84ABD2960414CA4A448E0D2C9364B4E1725BDA4F [clean] init<br />#004: 194D956F288B36FB46E46A124E59D466DE7C73B6 [clean] ld-2.3.2.so<br />#005: 7DF33561E2A467A87CDD4BB8F68880517D3CAECB [clean] libc-2.3.2.so<br />#006: 93A0BBC35FD4CA0300AA008F02441B6EAA425643 [clean] rc.sysinit<br />#007: 66F445E31575CA1ABEA49F0AF0497E3C074AD9CE [clean] bash<br />#008: F4F6CB0ACC2F1BEE13D60330011DF926D24E5688 [clean] libtermcap.so.2.0.8<br />#009: 346443AAD8E7089B64B2B67F1A527F7E2CA2D1E5 [clean] libdl-2.3.2.so<br />#010: 02385033F849A2A4BFB85FD52BCEA27B45497C6C [clean] libnss_files-2.3.2.so<br />#011: 6CB3437EC500767328F2570C0F1D9AA9C5FEF2F6 [clean] initlog<br />#012: FD1BCAEF339EAE065C4369798ACAADFF44302C23 [clean] hostname<br />#013: F6E44B04811CC6F53C58EEBA4EACA3FE9FF91A2E [clean] consoletype<br />#014: 12A5A9B6657EFEE7FD619A68DA653E02A7D8C661 [clean] grep<br />#015: 3AF36F2916E574884850373A6E344E4F2C51DD60 [clean] sed<br />#016: CE516DE1DF0CD230F4A1D34EFC89491CAF3D50E4 [clean] libpcre.so.0.0.1<br />#017: 5EE8CD72AAD26191879E01221F5E051CE5AAE95F [clean] setsysfont<br />#018: 8B15F3556E892176B03D775E590F8ADF9DA727C5 [clean] unicode_start<br />#019: F948CF91C7AF0C2AB6AD650186A80960F5A0DAB1 [clean] kbd_mode<br />#020: FF02DD8E56F0B2DCFB3D9BF392F2FCE045EFE0BC [clean] dumpkeys<br />#021: C00804432DFBC924B867FC708CB77F2821B4D320 [clean] loadkeys<br />#022: DE3AC70601B9BA797774E59BEC164C0DDF11982D [clean] setfont<br />#023: 7334B75FDF47213FF94708D2862978D0FF36D682 [clean] gzip<br />#024: AEC13AA4FF01F425ACACF0782F178CDFE3D17282 [clean] minilogd<br />#025: 09410DDC5FE2D6E7D8A7C3CF5BB4D51ED6C4C817 [clean] sleep<br />……………<br />PCR10<br />
  13. 13. 13<br />Linux Application Measurements<br />cat /proc/tpm/pcrs<br />PCR-00: 0A 2A B1 F6 56 EA ED 4C 53 F0 C7 9D 5E 05 61 37 51 B7 1C E5<br />PCR-01: 5F DB 12 AD B3 34 7D D6 90 63 46 72 D8 DE 02 1C F3 3C 00 F7<br />PCR-02: EB B3 BA AE E7 57 4B B6 37 AA AB 67 0F 9A C1 BC EB 6F 80 F3<br />PCR-03: 04 FD EC DD 50 1D AF 0F 62 4C 1F 99 60 12 CF 30 44 FF 46 10<br />PCR-04: 28 E3 E8 F0 CA 34 ED DD 58 AA 7E 71 F6 FC AE 08 C3 88 EB 05<br />PCR-05: E7 23 99 CD A3 1D 37 E4 35 61 B7 1A 85 68 3B 66 7F 51 B6 B4<br />PCR-06: 04 FD EC DD 50 1D AF 0F 62 4C 1F 99 60 12 CF 30 44 FF 46 10<br />PCR-07: 04 FD EC DD 50 1D AF 0F 62 4C 1F 99 60 12 CF 30 44 FF 46 10<br />PCR-08: DC 0E 38 C4 F4 46 F7 BC DF C8 83 CA CC 86 E2 69 50 C5 0E 66<br />PCR-09: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00<br />PCR-10: 50 48 FF 78 06 63 CB BF A5 F6 43 0B DA 41 1A 15 74 C3 1A 92<br />PCR-11: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00<br />PCR-12: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00<br />PCR-13: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00<br />PCR-14: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00<br />PCR-15: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00<br />
  14. 14. Static root of trust for measurement<br />Dynamic root of trust for measurement<br />Flicker: Minimal TCB Code Execution<br />Dynamic root of trust for measurement<br />
  15. 15. 15<br />Late Launch Background<br />Supported by new commodity CPUs<br />SVM for AMD<br />TXT (formerly LaGrande) for Intel<br />Designed to launch a VMM without a reboot<br />Hardware-based protections ensure launch integrity<br />New CPU instruction (SKINIT/SENTER) accepts a memory region as input and atomically:<br />Resets dynamic PCRs <br />Disables interrupts<br />Extends a measurement of the region into PCR 17<br />Begins executing at the start of the memory region<br />
  16. 16. 16<br />Dynamic Root of Trust for Measurementaka: Late Launch<br />Involves both CPU and TPM v1.2<br />Security properties similar to reboot<br />Without a reboot!<br />Removes many things from TCB<br />BIOS, boot loader, DMA-enabled devices, …<br />Long-running OS and Apps if done right<br />When combined with virtualization<br />VMM can be measured (MVMM)<br />Uptimes measured in years<br />Integrity of loaded code can be attested<br />Untrusted legacy OS can coexist with trusted software<br />Allows introduction of new, higher-assurance software without breaking existing systems<br />
  17. 17. 17<br />AMD/Intel Late Launch Extensions<br />AMD: Secure Virtual Machine (SVM)<br />Intel: Trusted eXecution Technology (TXT)<br />Formerly LaGrande Technology (LT)<br />Similarities:<br />Late launch of a measured block of code<br />Hardware support for virtualization<br />Differences:<br />AMD provides measured environment only<br />Intel adds authenticated code capabilities<br />The system’s chipset contains a public key to verify signed code<br />
  18. 18. 18<br />AMD Secure Virtual Machine<br />Virtualization support<br />DMA protection for memory<br />Intercept selected guest instructions / events<br />Much more…<br />Late launch with support for attestation<br />New instruction: SKINIT (Secure Kernel Init)<br />Requires appropriate platform support (e.g., TPM 1.2)<br />Allows verifiable startup of trusted software<br />Such as a VMM<br />Based on hash comparison<br />
  19. 19. 19<br />SKINIT (Secure Kernel Init)<br />Accepts address of Secure Loader Block (SLB)<br />Memory region up to 64 KB<br />SKINIT executes atomically<br />Sets CPU state similar to INIT (soft reset)<br />Disables interrupts<br />Enables DMA protection for entire 64 KB SLB<br />Causes TPM to reset dynamic PCRs to 0<br />Sends SLB contents to TPM<br />TPM hashes SLB contents and extends PCR 17<br />Begins executing SLB<br />
  20. 20. 20<br />SKINIT Security Properties<br />Verifier receives attestation after SKINIT<br />Knows SKINIT was used<br />Knows software TCB includes only the SLB<br />Knows exactly what SLB was executed<br />SLB can be written to provide add’l props.<br />Knows any inputs to SLB<br />Knows any outputs from SLB<br />Knows exactly when SLB finished executing<br />
  21. 21. 21<br />AMD SVM Security Discussion<br />Property: Verifiable untampered code execution<br />SKINIT + TCG 1.2 provide very strong security properties<br />Minimal TCB: Only hardware and application need to be trusted<br />A1<br />A2<br />A3<br />Operating System<br />Hardware<br />
  22. 22. 22<br />Secure Loader Block Layout<br />ESP<br />SL Runtime<br />Data Area<br />SL Stack<br />64 KB<br />SL Code and <br />Static Data<br />Length<br />SL Image<br />(hash area)<br />SL Entry Point<br />SL Header<br />Length<br />EP Offset<br />EAX<br />
  23. 23. 23<br />SKINIT TPM Operations<br />TPM v1.2 includes notion called locality<br />Similar to software privilege level<br />4 is highest, 0 is lowest<br />Certain PCRs associated with localities<br />PCR 17 is associated with locality 4<br />SKINIT is the only locality 4 operation<br />SKINIT sends contents of SLB to TPM<br />TPM hashes SLB to create a measurement<br />TPM resets PCR17, sets PCR17 = 0<br />Distinct from boot-time value of PCR17= -1<br />Allows verifier to know that SKINIT was executed<br />TPM performs PCR_Extend(17, hash(SLB))<br />
  24. 24. 24<br />Intel Trusted eXecution Technology<br />Safer Mode Extensions (SMX) and Virtual Machine Extensions (VMX)<br />SMX introduces Authenticated Code capabilities<br />AC module loaded into CPU-internal RAM<br />AC module contains a digital signature<br />Processor calculates hash and verifies signature<br />Execution isolated from external memory and bus<br />SMX introduces a GETSEC “leaf” instruction<br />GETSEC[CAPABILITIES] - get available capabilities<br />
  25. 25. 25<br />Intel TXT vs. AMD SVM<br />AMD SVM does not support authenticated code<br />Whether this will be significant is not yet known<br />AC needs code signed such that chipset can verify it<br /> Chipset needs public key, crypto capabilities<br />Additional complexity<br />Code update issues<br />AMD systems have been available for almost a year<br />Intel systems have only just become available<br />
  26. 26. 26<br />Safer Mode Extensions<br />Detecting and Enabling SMX.软件可以使用CPUID instruction来检测CPU对SMX操作的支持。软件将1放入EAX寄存器,执行CPUID,返回ECX的值的第6位指明了对SMX操作是否支持(即GETSEC指令是否可用)。<br />
  27. 27. 27<br />1 SMX Functionality<br /><ul><li>在处理器中通过GETSEC指令来提供对SMX的功能的支持。这条指令支持多个子功能。在GETSEC指令执行时由EAX中的值来决定执行哪个子功能(这些子功能共享同一个操作码,0F 37)。</li></li></ul><li>28<br />2 Enabling SMX Capabilities<br /><ul><li>系统软件通过设置CR4.SMXE[Bit 15]=1去打开SMX功能。如果没有打开就去执行会返回一个非法操作码异常(#UD)。
  28. 28. 如果CPUID的SMX标志位是0(CPUID.01H.ECX[Bit 6] = 0),那么设置CR4.SMXE[Bit 15]位的操作将返回一个general protection异常。
  29. 29. IA32_FEATURE_CONTROL MSR(在地址03AH)提供了配置VMX和SMX操作的控制位。</li></li></ul><li>29<br />3 SMX Instruction Summary<br />系统软件首先通过执行GETSEC[CAPABILITIES]指令来查询可用的GETSEC子功能。<br />
  30. 30. 30<br />3 SMX Instruction Summary<br />1 GETSEC[PARAMETERS] 返回SMX的相关参数信息<br />报告SMX操作的attributes, options and limitations。软件使用它来辨识操作限制或附加选项。The parameters index is input in EBX with the result returned in EAX, EBX, and ECX.<br />
  31. 31. 31<br />Tboot for Xen<br />
  32. 32. 32<br />Intel® Trusted Execution Technology<br />Removes BIOS/bootloader/OS/etc. from trust chain<br />Creates dynamic root of trust (DRTM)<br />Platform configuration protection<br />Reset memory protection<br />Safer Mode Extensions (SMX) <br />Intel TXT processor instructions<br />
  33. 33. 33<br />What is Trusted Boot (tboot)?<br />Open source, pre-kernel/VMM module<br />Uses Intel TXT to perform verified launch of OS kernel/VMM<br />Today only supports Xen<br />Project also contains tools for policy creation and Provisioning<br />Intel TXT Launch Control Policy (LCP)<br />Tboot Verified Launch policy<br />
  34. 34. 34<br />Trusted Boot provides a foundation for a Trusted Xen<br /><ul><li>Root of trust is in hardware: Intel TXT dynamic launch
  35. 35. Tboot is verified by Intel TXT Launch Control Policy (LCP)</li></ul>Part of measured launch<br />Can optionally verify BIOS<br /><ul><li>Tboot Verified Launch verifies Xen and Dom0 (+ initrd)</li></ul>Dom0 trust could be extended via IMA, disaggregation, etc.<br />
  36. 36. 35<br />Measured Launched Environment<br /><ul><li>Measured Launched
  37. 37. MLE Initialization
  38. 38. MLE Operation
  39. 39. MLE Teardown</li></li></ul><li>36<br />1.Measured Launched<br /><ul><li>Intel® TXT detection and processor preparation
  40. 40. Loading the SINIT AC module
  41. 41. Loading the MLE and processor rendezvous
  42. 42. Performing a measured launch.</li></li></ul><li>37<br />1.1 Intel® TXT detection and processor preparation <br /><ul><li>Intel® Trusted Execution Technology Detection and Processor Preparation </li></ul> This action is only performed by the ILP. <br /> CPUID(EAX=1); <br /> IF (SMX not supported) OR (VMX not supported) { <br /> Fail measured environment startup; <br /> } <br />// Enable SMX on ILP & check for Intel® TXT chipset <br /> CR4.SMXE = 1; <br /> GETSEC[CAPABILITIES]; <br /> IF (Intel® TXT chipset NOT present) { <br /> Fail measured environment startup; <br /> }<br />
  43. 43. 38<br />1.2 Loading the SINIT AC module<br /><ul><li>Intel® Trusted Execution Technology Detection and Processor Preparation </li></ul> This action is only performed by the ILP. <br /> Matching an AC Module to the Chipset Each AC module is designed for a specific chipset or set of chipsets.<br />
  44. 44. 39<br />1.3 Loading the MLE and processor rendezvous(1)<br /><ul><li>Loading the MLE </li></ul>System software allocates memory for the MLE and MLE page table. 不需要连续的内存空间<br />System software creates an MLE page table structure to map the entire MLE image. <br />The SINIT AC module will check that the MLE page table matches several special requirements <br />Calculate the MLE digest.<br />System software writes the physical base address of the MLE page table’s page directory to the Intel® TXT Heap. The size in bytes of the MLE image is also written to the Intel® TXT Heap<br />
  45. 45. 40<br />1.3 Loading the MLE and processor rendezvous(2)<br /><ul><li>Intel® Trusted Execution Technology Heap Initialization </li></ul>Information can be passed from system software to the SINIT AC module and from system software to the MLE using the Intel® TXT Heap. The SINIT AC module will also use this region to pass data to the MLE. <br />The system software launching the measured environment is responsible for initializing the following in the Intel® TXT Heap memory (this initialization must be completed before executing GETSEC[SENTER]):<br />(1)Initialize contents of the Intel® TXT Heap Memory<br />(2)Initialize contents of the OsMleData and OsMleDataSize (with the size of the OsMleData field + 8H) fields. <br />(3)Initialize contents of the OsSinitData and OsSinitDataSize (with the size of the OsSinitData field + 8H) fields. <br />The OsMleData structure has fields for specifying regions of memory to protect from DMA (PMR Low/High Base/Size) using VT-d.<br />
  46. 46. 41<br />1.3 Loading the MLE and processor rendezvous(3)<br /><ul><li>Rendezvousing Processors and Saving State </li></ul>如果是在OS启动后launching the measured environment 那么all processors should be brought to a rendezvous point before executing GETSEC[SENTER]. At the rendezvous point each processor will set up for GETSEC[SENTER] and save any state needed to resume after the measured launch. If processors are not rendezvoused before executing SENTER then the processors will loose their current operating state including possibly the fact that an in-service interrupt has not been acknowledged.<br />Clear Machine Check Status Registers; <br />Ensure CR0.CD=0, CR0.NW=0, and CR0.NE=1; <br />// Save current system software state in Intel® TXT Heap <br />Allocate memory for OsMleData; <br />Fill in OsMleData with system software state (including MTRR and IA32_MISC_ENABLE MSR states);<br />
  47. 47. 42<br />1.4 Performing a Measured Launch(1)<br /><ul><li>MTRR Setup Prior to GETSEC[SENTER] Execution </li></ul>System software must set up the variable range MTRRs (memory type range register)to map all of memory (except the region containing the SINIT AC module) to one of the supported memory types as returned by GETSEC[PARAMETERS]. <br />After MTRR setup is complete, the RLPs mask interrupts (by executing CLI), signal the ILP that they have interrupts masked, and execute halt. Before executing GETSEC[SENTER], the ILP waits for all RLPs to indicate that they have disabled their interrupts. If the ILP executed a GETSEC[SENTER] while an RLP was servicing an interrupt, the interrupt servicing would not complete, possibly leaving the interrupting device unable to generate further interrupts. <br />
  48. 48. 43<br />1.4 Performing a Measured Launch(2)<br /><ul><li>TPM Preparation </li></ul>System software must ensure that the TPM is ready to accept commands and that the TPM.ACCESS_0.activeLocality bit is clear before executing the GETSEC[SENTER] instruction. <br /><ul><li>Intel® Trusted Execution Technology Launch </li></ul>The ILP is now ready to launch the measuring process. System software executes the GETSEC[SENTER] instruction. <br />
  49. 49. 44<br />Measured Launched Environment<br /><ul><li>Any Measured Launched Environment (MLE) will generally consist of three main sections of code: the initialization, the dispatch routine, and the shutdown. </li></ul>The initialization code is run each time the Intel® TXT environment is launched. This code includes code to setup the MLE on the ILP and join code to initialize the RLPs.<br /> After initialization, the MLE behaves like the unmeasured version would have; in the case of a VMM, this is trapping various guest operations and virtualizing certain processor states.<br />Finally the MLE prepares for shutdown by again synchronizing the processors, clearing any state and executing the GETSEC[SEXIT] instruction.<br />
  50. 50. 45<br />2.MLE Initialization<br />//1.MLE entry point – ILP and RLP(s) enter here <br />Load CR3 with MLE page table pointer; <br />Enable paging; <br />Load the GDTR with the linear address of MLE GDT; <br />Long jump to force reload the new CS; <br />Load MLE SS, ESP; <br />Load MLE DS, ES, FS, GS; <br />Load the IDTR with the linear address of MLE IDT; <br />Initialize exception handlers; <br />// 2.状态生效<br />Check and restore MTRR settings from OsMleData area; <br />Validate system memory map against MDRs <br />Validate VT-d DMAR table <br />Validate VT-d PMR settings against expected values <br />Restore IA32_MISC_ENABLE MSR from OsMleData<br />
  51. 51. 46<br />2.MLE Initialization<br />//3. Wake RLPs <br />Initialize memory protection and other data structures; <br />Build JOIN structure; <br />LT.MLE.JOIN = physical address of JOIN structure; <br />IF RLP exist <br /> GETSEC[WAKEUP]; <br />Wait for all processors to reach this point; <br />在processors间做一致性检测;<br />// 4.Enable VMX <br />CR4.VMXE = 1; <br />// 5.Start VMX operation <br />Allocate and setup the root controlling VMCS, execute <br />VMXON(root controlling VMCS); <br />
  52. 52. 47<br />2.MLE Initialization<br />// 6.Set up the guest container <br />Allocate memory for and setup guest VMCS; <br />VMCLEAR guest VMCS; <br />VMPTRLD guest VMCS; <br />Initialize guest VMCS from OsMleData area; <br />// 7.All processors launch back into guest <br />VMLAUNCH guest;<br />
  53. 53. 48<br />3.MLE Operation<br /><ul><li>The dispatch routine is responsible for handling all VMExitsfrom the guest. The guest VMExits are caused by various situations, operations or events occurring in the guest. The dispatch routine must handle each VMExit appropriately to maintain the measured environment. In addition, the dispatch routine may need to save and restore some of processor state not automatically saved or restored during VM transitions. The MLE must also ensure that it has an accurate view of the address space and that it restricts access to certain of the memory regions that the GETSEC[SENTER] process will have enabled. The following subsections describe various key components of the MLE dispatch routine.</li></li></ul><li>49<br />3.1 Address Space Correctness<br /><ul><li>It is likely that most MLEs will rely on the e820 memory map to determine which regions of the address space are physical RAM and which of those are usable (e.g. not reserved by BIOS). However, as this table is created by BIOS it is not protected from tampering prior to a measured launch. An MLE, therefore, cannot rely on it to contain an accurate view of physical memory.
  54. 54. After a measured launch, SINIT will provide the MLE with an accurate list of the actual RAM regions as part of the SinitMleData structure of the Intel® TXT Heap (see Appendix C.4). The SinitMDR field of this data structure specifies the regions of physical memory that are valid for use by the MLE. This data structure can also be used to accurately determine SMRAM and PCIE extended configuration space, if the MLE handles these specifically. </li></li></ul><li>50<br />3.2 Address Space Integrity<br /><ul><li>There are several regions of the address space (both physical RAM and Intel® TXT chipset regions) that have special uses for Intel® TXT. Some of these should be reserved for the MLE and some can be exposed to one or more guests/VMs. </li></li></ul><li>51<br />3.3 Physical RAM Regions <br /><ul><li>There are two regions of physical RAM that are used by Intel® TXT and are reserved by BIOS prior to the MLE launch. These are the SINIT AC module region and the Intel® TXT Heap. Each region’s base address and size are specified by Intel® TXT configuration registers (e.g. LT.SINIT.BASE and LT.SINIT.SIZE).
  55. 55. The SINIT and Intel® TXT Heap regions are only required for measured launch and may be used for other purposes afterwards. However, if the measured environment must be re-launched (e.g. after resuming from S3 state), the MLE may wish to reserve and protect these regions.</li></li></ul><li>52<br />3.4 Intel® Trusted Execution Technology Chipset Regions<br /><ul><li>Intel® Trusted Execution Technology Configuration Space
  56. 56. The configuration register space is divided into public and private regions. The public region generally provides read only access to configuration registers and the MLE may choose to allow access to this region by guests. The private region allows write access, including to the various command registers. This region should be reserved to the MLE to ensure proper operation of the measured environment.
  57. 57. Intel® Trusted Execution Technology Device Space</li></li></ul><li>53<br />3.5 Protecting Secrets<br /><ul><li>If there will be data in memory whose confidentiality must be maintained, then the MLE should set the Intel® TXT secrets flag so that the Intel® TXT hardware will maintain protections even if the measured environment is lost before performing a shutdown (e.g. hardware reset). This can be done by writing to the LT.CMD.SECRETS configuration register. The teardown process will clear this flag once it has scrubbed memory and removed any confidential data</li></li></ul><li>54<br />3.6 Machine Specific Register Handling<br /><ul><li>3.7 ACPI Power Management Support (S-State Transitions S3~S5)
  58. 58. Before tearing down the Intel® TXT environment, the MLE may remove secrets from memory (clearing pages with secrets) or encrypt secrets for later use (e.g. for a later measured environment launch). Once this operation is complete the MLE must issue the LT.CMD.NO-SECRETS command to clear the secrets flag. After this command is issued, the MLE may allow a transition to a S3, S4 or S5 sleep state.</li></li></ul><li>55<br />4 MLE Teardown <br />Rendezvous processors in guest OS; <br />All processors VMCALL teardown in MLE; <br />Rendezvous all processors in MLE teardown routine; <br />All processors read guest state from VMCS, store values in <br />memory; <br />// Remove and encrypt all secrets from registers and memory<br />// Stop VMX operation<br />// RLPs wait while ILP executes SEXIT<br />// Transition back to the guest OS<br />
  59. 59. Static root of trust for measurement<br />Dynamic root of trust for measurement<br />Flicker: Minimal TCB Code Execution<br />Flicker: Minimal TCB Code Execution<br />
  60. 60. 57<br />Trusted Computing Base (TCB)<br />…<br />…<br />App<br />App<br />1<br />App<br />App<br />1<br />S<br />S<br />OS<br />OS<br />Shim<br />DMA Devices <br />DMA Devices <br />CPU, RAM<br />TPM, Chipset<br />CPU, RAM<br />TPM, Chipset<br />(Network, Disk,<br /> USB, etc.)<br />(Network, Disk,<br /> USB, etc.)<br />
  61. 61. 58<br />TCB Reduction with Flicker<br />…<br />App<br />App<br />1<br />App<br />Today, TCB for sensitive code S:<br />Includes App<br />Includes OS<br />Includes other Apps<br />Includes hardware<br />With Flicker, S’s TCB:<br />Includes Shim<br />Includes some hardware<br />S<br />OS<br />Shim<br />CPU, RAM<br />TPM, Chipset<br />DMA Devices <br />(Network, Disk,<br /> USB, etc.)<br />
  62. 62. 59<br />Flicker’s Properties<br />Isolate security-sensitive code execution from all other code and devices<br />Attest to security-sensitive code and its arguments and nothing else<br />Convince a remote party that security-sensitive code was protected<br />Add &lt; 250 LoC to the software TCB<br />S<br />Software<br />TCB<br />&lt; 250 LoC<br />Shim<br />
  63. 63. 60<br />Adversary Capabilities<br />…<br />App<br />App<br />1<br />Run arbitrary code with maximum privileges<br />Subvert any DMA-enabled device<br />E.g., network cards, USB devices, hard drives<br />Perform limited hardware attacks<br />E.g., power cycle the machine<br />Excludes physically monitoring/modifying CPU-to-RAM communication<br />OS<br />S<br />Shim<br />DMA Devices <br />CPU, RAM<br />TPM, Chipset<br />(Network, Disk,<br /> USB, etc.)<br />
  64. 64. 61<br />App<br />RAM<br />OS<br />Module<br />S<br />Shim<br />SKINIT<br />Reset<br />Execution Flow<br />App<br />OS<br />Outputs<br />Inputs<br />0<br />0<br />0<br />Module<br />S<br />Module<br />Shim<br />TPM<br />…<br />PCRs:<br />CPU<br />K-1<br />
  65. 65. 62<br />S<br />Shim<br />Attestation<br />TPM<br />PCRs:<br />Inputs<br />…<br />Outputs<br />K-1<br />TPM<br />…<br />PCRs:<br />K-1<br />
  66. 66. 63<br />App<br />App<br />5<br />App<br />4<br />App<br />3<br />App<br />2<br />App<br />1<br />…<br />S<br />OS<br />TPM<br />PCRs:<br />0<br />0<br />0<br />Inputs<br />What code are<br />you running?<br />S<br />…<br />Shim<br />Outputs<br />Inputs<br />Outputs<br />K-1<br />S<br />)<br />(<br />Shim<br />Sign<br />, K-1<br />(<br />)<br />Sign<br />, K-1<br />Attestation<br />Versus<br />
  67. 67. 64<br />S<br />S<br />S<br />S<br />Shim<br />Shim<br />Shim<br />Shim<br />S<br />S<br />S<br />Shim<br />Shim<br />Shim<br />Context Switch with Sealed Storage<br /><ul><li>Seal data under combination of code, inputs, outputs
  68. 68. Data unavailable to other code</li></ul>OS<br />Data<br />PCRs:<br />PCRs:<br />…<br />…<br />Time<br />
  69. 69. 65<br />Developing With Flicker <br />Sensitive code linked against the Flicker library<br />Customized linker script lays out binary<br />Application interacts with Flicker via a Flicker kernel module<br />Made available at:<br />/proc/flicker/output<br />#include “flicker.h”<br />const char* msg = “Hello, world”; <br />void flicker_main(void *inputs) { <br />}<br /> for(int i=0;i&lt;13;i++) <br /> OUTPUT[i] = msg[i]; <br />
  70. 70. 66<br />Default Functionality<br />Shim can execute arbitrary x86 code but provides very limited functionality<br />Fortunately, many security-sensitive functions do not require much<br />E.g., key generation, encryption/decryption, FFT<br />Functionality can be added to support a particular security-sensitive operation<br />We have partially automated the extraction of support code for security-sensitive code <br />
  71. 71. 67<br />Existing Flicker Modules<br />OS Protection Memory protection, ring 3 execution<br />Crypto Crypto ops (RSA, SHA-1, etc.)<br />Memory Alloc. Malloc/free/realloc<br />Secure Channel Secure remote communication <br />TPM Driver Communicate with TPM<br />TPM Utilities Perform TPM ops<br />
  72. 72. 68<br />Application: Rootkit Detector<br />Run detector<br />OS<br />Administrator can check the integrity of remote hosts<br />E.g., only allow uncompromised laptops to connect to the corporate VPN<br />…<br />App<br />1<br />App<br />n<br />OS<br />OS<br />D<br />Shim<br />Hardware<br />
  73. 73. 69<br />S<br />Shim<br />OK!<br />S<br />K<br />Shim<br />K<br />EncryptK(passwd)<br />S<br />S<br />Shim<br />Shim<br />nonce<br />Start<br />Application: SSH Passwords<br />Gen {K, K-1}<br />K-1<br />K-1<br />EncryptK(passwd)<br />EncryptK(passwd)<br />passwd<br />
  74. 74. 70<br />Other Applications Implemented<br />Enhanced Certificate Authority (CA)<br />Private signing key isolated from entire system<br />Verifiable distributed computing<br />Verifiably perform a computational task on a remote computer<br />Ex: SETI@Home, Folding@Home, distcc<br />
  75. 75. 71<br />Generic Context-Switch Overhead<br />Each Flicker context switch requires:<br />SKINIT<br />TPM-based protection of application state<br />Results<br />
  76. 76. 72<br />Rootkit Detection Performance<br />37 ms Disruption<br />Non-Disruptive<br />Running detector every 30 seconds has negligible impact on system throughput<br />
  77. 77. 73<br />SSH Performance<br />Setup time (217 ms) dominated by key generation (185 ms)<br />Password verification (937 ms) dominated by TPM Unseal (905 ms)<br />Adds &lt; 2 seconds of delay to client login<br />
  78. 78. 74<br />Optimizing Flicker’s Performance<br />Non-volatile storage <br />Access control based on PCRs<br />Read in 20ms, Write in 200 ms<br />Store a symmetric key for “sealing” and “unsealing” state<br />Reduces context-switch overhead by an order of magnitude<br />
  79. 79. 75<br />Breakdown of Late Launch Overhead<br />After ~4KB, code can measure itself<br />
  80. 80. 76<br />Late Launch Performance<br />CPU<br />CPU<br />CPU<br />MemoryController<br />MemoryController<br />MemoryController<br />Late launch requires APs to stop execution<br />More cores = more expensive<br />STOP<br />…<br />CPU<br />CPU<br />RAM<br />MemoryController<br />MemoryController<br />RAM<br />TPM<br />Other CPUsI/O Devices<br />Other CPUsI/O Devices<br />TPM<br />
  81. 81. 77<br />Overheads and Recommendations<br />O1 Late launch and TPM sealed storage overhead on every context switch<br />R1 Secure context switch between sensitive applications without TPM<br />O2 Other cores must halt to enable late launch<br />R2 Secure execution on multiple CPUs concurrently<br />O3 TPM equipped to store measurements from only one late launch<br />R3 TPM support for concurrent Flicker sessions<br />
  82. 82. 78<br />New States for Memory Pages<br />Avoid TPM for short-term data protection<br />Memory Controller already supports DMA protection vector<br />All<br />Launch<br />Exit<br />Sensitive<br />Application<br />CPU i<br />Resume<br />Suspend<br />None<br />Memory<br />
  83. 83. 79<br />Concurrent Flicker Sessions<br />Other CPUs continue to perform useful work<br />Memory Controllers isolate secure state<br />CPU<br />CPU<br />RAM<br />MemoryController<br />MemoryController<br />Other CPUsI/O Devices<br />Other CPUsI/O Devices<br />TPM<br />
  84. 84. 80<br />Add Secure Execution PCRs to TPM<br />Each SE PCR holds state for one Flicker session<br />Bounds number of concurrent Flicker sessions<br />TPM<br />StaticPCRs<br />DynamicPCRs<br />SecureExecutionPCRs<br />

×