This is a position paper that I originally circulated inside the firmware
community at X. I’ve gotten requests for a public link, so I’ve cleaned it up
and posted it here. This is, obviously, my personal opinion. Please read the
whole thing before sending me angry emails.
tl;dr: C/C++ have enough design flaws, and the alternative tools are in good
enough shape, that I do not recommend using C/C++ for new development except in
extenuating circumstances. In situations where you actually need the power of
C/C++, use Rust instead. In other situations, you shouldn’t have been using
C/C++ anyway — use nearly anything else.
A webserver is a computer, connected to the public internet, that does things
(serves pages, etc.) whenever anyone asks it to. This makes it an easy thing
to attack: the first step toward attacking a computer is usually getting it to
do your bidding, and a webserver does your bidding every time you click a link.
My system logs show that I get attacked several times a day, like (I imagine)
most computers on the Internet. Fortunately, most attacks bounce off — not
because I have some magic security-foo, but rather because the software I’m
using — specifically publicfile — doesn’t work the way the attackers
expect it to.
While I am not so naive or foolish as to say that my server is “secure” —
I’m sure it has some exploitable hole, and it runs in a distant facility that
probably forgets to lock the doors sometimes — these attacks are of mostly
Here’s some data I’ve collected from the past month or so of attacks. I figure
this might help someone else detect or prevent an attack in the future.
Derek L. Schuff,
Cliff L. Biffle and
This paper, presented at PLDI ’11, describes a key innovation behind Native
Client, which is (as far as I’m aware) an industry first: the ability to verify
the safety of a code-generating program, like a JIT or language runtime, and
that of its output, on the fly.
We can even support self-modifying code, with very little runtime overhead for
verification. I firmly believe that active runtimes involving some degree of
JIT code generation are the future, and this paper shows that we don’t have to
sacrifice security or reliability to support them.
I designed the mechanisms behind this technology with Bennet Yee and David Sehr,
for x86, x86-64, and ARM processors. The rest of the authors did the hard part:
implementing it in a portable way and shipping it to the masses. If you’re
using Chrome, you’re already using this technology.
We received an internal Google award for this paper.
Cliff L. Biffle,
Karl Schimpf and
Software Fault Isolation (SFI) is an effective approach to sandboxing binary
code of questionable provenance, an interesting use case for native plugins in
a Web browser. We present software fault isolation schemes for ARM and x86-64
that provide control-flow and memory integrity with average performance
overhead of under 5% on ARM and 7% on x86-64. We believe these are the best
known SFI implementations for these architectures, with significantly lower
overhead than previous systems for similar architectures. Our experience
suggests that these SFI implementations benefit from instruction-level
parallelism, and have particularly small impact for workloads that are data
memory-bound, both properties that tend to reduce the impact of our SFI
systems for future CPU implementations.