Communications - June 2012

Flicker was implemented for both 32-bit Windows and Linux running on AMD and Intel CPUs (http://flickertcb. sourceforge.net) and includes useful code modules PALs can choose to include (such as for memory management, TPM operations, cryptographic operations, and secure channels). Using them, Flicker has since been applied to several broad classes of applications. To illustrate stateless applications, Flicker provides verifiable isolated execution of a kernel rootkit detector on a remote machine. To illustrate applications for which integrity protection of application state suffices, Flicker helps verify execution of a distributed computing application based on the Berkeley Open Infrastructure for Network Computing framework. 3 Finally, to illustrate applications with state requiring secrecy and integrity, Flicker helps protect computations performed with the private key for a certificate authority, the passwords for an SSH server and for a full-disk encryption utility, and the content of a differentially private database.

To summarize this evaluation, invoking the SKINIT instruction requires ∼48ms, while secure storage operations take ∼22ms, meaning a typical Flicker session requires ∼70ms, plus the time needed for the application-specific PAL to execute. Generating a TPM quote for the Flicker session is by far the slowest operation; depending on the TPM, that quote can take ∼362ms–756ms. Fortunately, it can be computed in parallel with untrusted code since it is performed outside the Flicker environment. In general, Flicker has little effect on the performance of untrusted code, and the OS remains stable. Frequent brief Flicker sessions have little effect on system performance. Longer-running Flicker sessions may produce input lag or dropped network packets, but our experiments indicate Flicker does not corrupt data transfers (such as between USB and disk).

suggested architectural improvements. Overall, experiments identified two significant performance bottlenecks for minimal TCB execution on current CPU architectures: inability to execute PALs and untrusted code simultaneously on different cores of a multicore machine and slow TPM op-

erations to protect PAL state during a context switch between secure and insecure execution.

Alleviating them involves a number of recommendations to hardware manufacturers14, 17, 21 to support an execution model in which multiple PALs can execute in parallel with legacy software. The key ones are a hardware mechanism that isolates the memory pages belonging to a PAL from all other code and for a hardware context switch mechanism that efficiently suspends and resumes PALs without exposing a PAL’s execution state to other code.

A secure execution control block
(SECB) is defined as a structure that
holds PAL state and resource alloca-
tions for launching a PAL and for stor-
ing its state when not executing. Figure
3 outlines the proposed life cycle of a
PAL. To begin execution of a PAL de-
scribed by a newly allocated SECB, a
new CPU instruction, secure launch,
or SLAUNCH, can be added that takes
as its argument the starting physical
address of an SECB. It combines the
hardware virtual machine manage-
ment data structures on AMD and Intel
CPUs with the security functionality of
a DRTM operation.

figure 2. Timeline of steps needed to execute a PAL.

the slB includes the PAl and the code needed to initialize and terminate the Flicker session. the gap in the time axis indicates the Flicker kernel module must be loaded only once.

A c c e pt u ninit. S L B Load Flicker m od.

A cce pt in puts
Initialize SL B
Suspend OS
SKINIT
Flicker Session
Return outputs
Extend PCR
Resum e OS
Cleanup
Execute PAL
Piece of Application Logic
SLB

figure 3. PAL life cycle.

these states in the PAl life cycle are for illustrative purposes and not necessarily represented explicitly in the system; measured flag, or MF, is set to indicate the CPu has measured the current PAl.