Re: Are memory safety and maximized data volatility mutually exclusive?

On Thu, Oct 8, 2015 at 4:23 AM, rmeijer <rmeijer-qWit8jRvyhVmR6Xm/[email protected]> wrote:

> In C or C++ I don't have memory safety, yet the lack of memory safety
> gives me the power to overwrite sensitive data at the moment that the
> sensitive data is no longer functionally required. That means if I make a
> memory dump of the process a fraction of a second later, there is no trace
> of the sparse caps left.
>

It's not clear that you can reliably achieve this in C/C++, though it would
probably work *most* of the time.

The language standards are quite nice about letting compilers elide code
that looks like make-work (why write a zero to this memory if no one will
read it in the future?). A work around might be possible using some
assembly or other tricks, but will likely still rely on the compiler not
doing something unexpected.

Colin Percival wrote an interesting series of blog posts about this issue:
http://www.daemonology.net/blog/2014-09-06-zeroing-buffers-is-insufficient.html
.

Making sure things are deleted on time is an interesting question. For
high-level languages, our research group has studied this
"information-erasure" problem in the context of the information-flow typed
language Jif [1], and more recently for Java (but particularly considering
the use of cryptography to support erasure) [2]. In these languages, you
label information with dynamic flags about when it needs to be erased, and
then either statically make sure it is gone before the flag is set or
dynamically overwrite the sensitive data.

We have some on-going work on how to make sure those guarantees apply at
the system level in addition to the language-level, but nothing ready to
share yet.

Cheers,
Scott

[1] http://people.seas.harvard.edu/~chong/pubs/csf08_enforcement.pdf
[2] http://thinkmoore.net/csf15_crypto_erasure.pdf
[3] Prototype source-to-source compiler for Java:
https://github.com/HarvardPL/cryptoerase

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