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.
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
Resum e OS
Piece of Application Logic
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.