Re: [friam] SOSP History Day

Trying again after changing my subscription address -- sorry if this is a duplicate.

On 08/10/15 15:22, Mark S. Miller wrote:
> I do not imagine a world with fewer exploitable bugs.
> I imagine a world in which much less is at risk to most bugs.

It isn't difficult to imagine a world with both fewer exploitable bugs, and
with less at risk to most remaining bugs. The former requires better
programming languages, tools, and analysis techniques -- which are
complementary to reducing the latter risk.

I'm certainly focussing on both problems in my language research, to the extent
that I do not view them as separate problems.

At the risk of oversimplifying a little:

  "total exploitability" = sum over bugs { exploitability of each bug }

The reasons why this is an oversimplification are:

* the "exploitability" of a bug is not entirely well-defined, and is perhaps not
  best modelled with a linear metric;
* the exploitability of a bug is not independent of the kind of bug, and any
  particular technique for reducing bugs will not be effective on all kinds of
  bug equally;
* an attack may need to exploit multiple bugs, so the "total exploitability"
  is not exactly what we care about.

Nevertheless, it is at least a plausible hypothesis that, to a first order
approximation, we have a *multiplicative* contribution to overall security from
reducing the incidence of bugs and from reducing their (typical) exploitability.

Of course we do actually care about our programs being correct, not just secure.
Also, incorrectness can lead to insecurity via more subtle routes than the trivial
buffer overflows and injections that we've been used to patching so far.

For instance, here is a real bug in some versions of gcc that I consider to be
quite instructive:

  <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65307>

  The following code sample exhibits a bug in a gcc -O2 optimization pass.
  Namely, having defined two() and six() with the obvious return values, the
  value of two() * 2 + six() * 5 gets an assembly of 1 shl 5 (i.e. 32, instead
  of the correct 34).

Would you trust an implementation of a cryptographic algorithm compiled with
that gcc?

Or how about this bug, which could affect the correctness of a message passing
implementation built on top of an atomic exchange primitive:

  <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60272>

(This is a problem even if applications don't use atomic exchange directly, as
they probably shouldn't. Furthermore, it's a race condition that might not show
up in testing.)

To me it's quite clear that we will not be able to trust computer systems unless
and until they are built on formally verified foundations -- and that this is
complementary to building them as capability systems (indeed, it may *only be
feasible* for capability systems). I am not suggesting that we throw up our hands
at the fact that such foundations are not available yet and consider everything
equally insecure; however, it is an issue we should be working on *now*.

-- 
Daira Hopwood  ⚧Ⓐ

_______________________________________________
cap-talk mailing list
[email protected]
http://www.eros-os.org/mailman/listinfo/cap-talk

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)

iQEcBAEBAgAGBQJWHQvgAAoJEAZ/SSCYzydigsUIALbTlUAMJ7FxZGPeJpmCulFw
4QclK6jpPtXRBqzecOlhSyLp0RfKL+mC16ZfW7Jk4JYeCCNJP0DK4b717dkUTfHf
JkU/DmdZ2jWLiWyU91MjXCFpGA6LsolewbQk0G/fKgmbsQGzbyBzliZHDsD9dO5A
vPlT/uigQQYe7e5OXSb97CUSabQ6MKsHaqwKsprtj7fKOrxQc0wxvEjLNHzUUeR7
rwD8kz1HgAaDYUvRBBtrHa5Ey184AbNmTRCKPwmXaHmBYhixa/lGXryvh5pGXPKu
J+2Dhnri+01KjOn79ofawxseOS1bhYm5goqwNY3rnIjXMsUdCjYBAHMKZ2oSxGU=
=RrBn
-----END PGP SIGNATURE-----