Secure code execution. This section describes Flicker as implemented on an AMD system (see Figure 2); the implementation is similar on an Intel system. To take advantage of Flicker, application developers must provide the security-sensitive code (called the piece of application logic, or PAL) selected for Flicker protection as an x86 binary and define its interface with the rest of their application; tools have been developed to aid in automating this process. To create a secure loader block, or SLB (supplied as an argument to the DRTM instruction, SKINIT), application developers link PAL against a code module developed to perform the steps necessary to set up and tear down the Flicker session.

Since SKINIT is a privileged instruction, when executing the resulting SLB, the application passes it to a kernel module that allocates memory, initializes various values in the SLB, and handles untrusted setup and teardown operations. The kernel module is not included in the trusted computing base (TCB) of the application, since its actions are verified.

Flicker achieves its properties through the DRTM capabilities outlined earlier. Rather than launch a VMM, it pauses the current execution environment (such as the untrusted OS), saving information about the kernel’s page tables to memory, along with the content of key registers (such as CR0, CR3, GDTR, IDTR, and TR). On multicore machines, execution must be halted on all but the bootstrap processor, and the other cores must be sent an INIT inter-processor interrupt so they respond correctly to a handshaking synchronization step performed during execution of SKINIT.

The Flicker session begins with execution of the SKINIT instruction, which receives the SLB selected for Flicker protection as an argument. As described earlier, SKINIT resets the CPU state, adds entries to the device-exclusion vector to disable the DMA to the memory region containing the SLB, disables interrupts (including system-management interrupts) to prevent the previously executing code from regaining control, disables debugging support, even for hardware debuggers, and extends a hash of the SLB into a PCR in the TPM. Finally, it hands control

A cuckoo attack is
possible because
the malware on
the local machine
has access to a
“TPM oracle”
that provides
TPM-like answers
without providing
TPM security
guarantees.

to Flicker’s initialization routine. To simplify execution of PAL code, Flicker loads the global descriptor table; loads the CS, DS, and SS registers; transitions to ring 3 (user space) execution; and calls the PAL, providing the address of PAL inputs as a parameter. When PAL execution terminates, Flicker cleans up any trace of the security-sensitive code’s execution by clearing out memory and register content. Finally, it resumes the previous execution environment. This resumption entails returning to ring 0 (kernel) execution, restoring the saved OS state, re-enabling paging interrupts and jumping back to kernel code.

Since Flicker’s protections are deployed only on demand, Flicker induces no performance overhead or feature reduction during regular computer use. Limiting Flicker’s persistence also strengthens its security guarantees, since it avoids the complexity (and potential vulnerability) of solutions based on a VMM or a security kernel. Hence, the core Flicker system was implemented with a TCB of only 250 lines of code.

However, non-persistence poses challenges of its own. For instance, to enable more complex applications, TPM-based secure storage must be leveraged to maintain state across Flicker sessions. Preventing a variety of subtle attacks on this saved state requires developing additional protocols. 22 A platform using Flicker can convince remote parties a Flicker session executed with a particular PAL. 18 To provide result integrity, when PAL execution terminates, Flicker extends PCR 17 with hashes of the PAL’s input and output parameters. It then extends PCR 17 with a fixed public constant, providing two powerful security properties. First, it prevents other software from extending values into PCR 17 and attributing them to the PAL; the fact that SKINIT resets PCR 17 to 0 prevents malicious software from extending values before the Flicker session. Second, it revokes access to any secrets kept in the TPM’s secure storage that might have been available during PAL execution. Combining these techniques enables a PAL to communicate securely, with both secrecy and integrity protections, with a remote party through a secure cryptographic channel.