well-behaved PAL calls SFREE, which clears the memory allocated to the PAL, as well as any microarchitectural state that might contain sensitive data, and marks the memory pages with ALL. Likewise, the untrusted OS may kill a PAL via SKILL, clearing the PAL’s state before freeing the associated memory pages.

Also recommended is a PAL pre-emption timer in the CPU that can be configured by the untrusted OS. When the timer expires or a PAL voluntarily yields (via a new CPU instruction, secure yield, or SYIELD), the PAL’s CPU state should automatically and securely be written to its SECB by hardware, all sensitive microarchitectural state should be cleared, and control should be transferred to an appropriate handler in the untrusted OS.

The untrusted OS can resume a PAL by executing SLAUNCH on the desired CPU, parameterized with the physical address of the PAL’s SECB. The PAL’s measured flag indicates to the CPU that the PAL has been measured and is only being resumed, not launched for the first time. During PAL resumption, the SLAUNCH instruction signals the memory controller that the PAL’s state should be accessible to the CPU on which the PAL is executing. Note that the PAL may execute on a different CPU each time it resumes. To enable multicore PALs, if a CPU attempts to resume an already executing PAL, that CPU will be added to the pool of CPUs available to the PAL.

The recommendations outlined here eliminate use of TPM operations during context switches and require the TPM to measure the PAL only once (instead of on every context switch). An implementation of these recommendations would be expected to achieve PAL context switch times on the order of those possible using hardware virtualization support, or 0.6µs on current hardware. This performance reduces the overhead of context switches by orders of magnitude, making switching in and out of a PAL much more practical.

Flicker thus provides a solid foundation for constructing secure systems that operate in conjunction with standard software; developers of security-sensitive code modules need to trust only their own code, along with as few as 250 lines of Flicker code, to protect the secrecy and integrity of the code’s execution. Flicker guarantees these properties, even if the BIOS, OS, and DMA-enabled devices are all malicious. The current implementation ( http://flickertcb.sourceforge.net/) offers reasonable performance for many applications; the hardware recommendations here would enable many more.

 

Leveraging secure Code execution If secure code execution can be provided on endhosts, the next frontier would be to examine how such trust can be extended into the network to improve the performance and efficiency of network applications. That is, if endhosts (or at least portions of each endhost) can be

figure 4. Assayer components.

the relying party (such as a mail server or an isP) delegates inspection of clients to one or more verifiers and configures one or more filters with information about the verifiers. the filters check the client’s annotation, then act on the information in the annotation; for example, a filter might drop the message or for ward it at a higher priority to the relying party.

Verifier Setup

3. Attestation

4. Sender Token

1.ClientPolicy

2. Verifier Info

 

Use Client

5. Message + Annotation

Filter
Relying
Party

trusted, then network infrastructure no longer must arduously and imprecisely reconstruct data already known by the endhosts. For instance, suppose a mail server wants to improve the accuracy of its spam identification using host-based information. A 2009 study found the average and standard deviation of the size of email messages sent in the past 24 hours are two of the best indicators of whether a given email message is spam or legitimate. 9 This data is easy for an endhost to collect but difficult for a single mail recipient to obtain.

As an initial exploration of how endhost hardware security features can be used to improve the network, a general architecture called Assayer was designed for securely conveying endhost information to network elements. 21, 24 While Assayer may not represent the optimal way to convey this information, it is a valuable first step for highlighting the various issues. For example, is it possible to provide useful host-based information while also protecting user privacy? Which cryptographic primitives are needed to verify this information in a secure and efficient manner? Initial findings suggest improved endhost security can improve the security and efficiency of the network while reducing the complexity of in-network elements. 21, 24

Naively, hardware-based attestation, as discussed earlier, might be used for each piece of information sent to the network. Also returning to an earlier example, a mail server might ask each client to include an attestation in every email message. The mail server’s spam filter could verify the attestation, then incorporate the host-provided information into its classification algorithm. Any legacy traffic arriving without an attestation could simply be processed by the existing algorithms. Unfortunately, checking attestations is time-consuming and requires interaction with the client machine. Even if such checks are feasible for an email filter, they would be unacceptable for other applications (such as distributed denial-of-service, or DDoS, mitigation) requiring per-packet checks at line rates. Likewise, labeling outbound traffic with mandatory access control labels, as proposed by McCune et al. 15 works well in tightly