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.