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

There is nothing fundamentally problematic about combining GC with
destroying sensitive data as soon as possible. But it's tricky.

But I do think you have a good point that it's not a particularly prominent
topic, and perhaps deserves more attention.

Before talking about GC guarantees, I'll recap my own thoughts on why data
destruction is important even in a capabilities-secure environment:

1. When I first read your email, I had a knee-jerk response of "in a
capabilities secure system, data destruction isn't important, since it's
possible to control the capability to read that data".
2. I think my initial thought was wrong: there are always other attacks, in
particular non-software attacks.
3. So data destruction is orthogonal to capabilities.
4. And capabilities are orthogonal to GC.
5. But data destruction is not orthogonal to GC: it's related to
deterministic finalisation.

Deterministic finalisation in GC is tricky. While it's sometimes thought of
as an RAII issue, and about stack allocation and unwinding, deterministic
finalisation is of course also a heap issue - a programmer explicitly
freeing memory is a finalisation commitment point. As you point out,
reference counting (like in Python) can make finalisation more likely to
occur when the programmer expects it, but only if you have non-cyclic data.
A functional language can ensure non-cyclic data, but reference counting
also has performance issues (particularly in FP).

Non-deterministic finalisation in GC allows data destruction in the
finalisation phase, but has two problems: "non-deterministic" for most
languages can mean "never" and finalisation introduces the possibility of
resurrection.

Now I transition into the "shameless plug" portion: my project is Pony (
ponylang.org), so I'll talk about how to achieve this (to some degree) in
Pony.

Good things:

* Pony GC is per-actor, and there's an opportunity for GC at the conclusion
of every actor behaviour.
* The programmer can indicate that the runtime should GC the current actor
when the current behaviour finished by making a call (and, "fairly soon",
will be able to force a GC pass during a behaviour).
* Since GC is per-actor, this isn't a big GC pause situation - it is O(n)
on the number of objects in the actor's reachable set, with a low k and no
thread synchronisation required, so this is ok to do a lot.
* Pony has resurrection-free finalisation. You can put a finaliser on an
object that holds sensitive data without living in fear of your runtime.

Bad things:

* Pony finalisers can make C FFI calls (if trusted to do so) and can read
data, but can't modify Pony objects themselves (to prevent resurrection).
You can get around this by using the C FFI to overwrite Pony objects, but
that kind of defeats the purpose of memory safety. And it would require
your code to be indicated as "trusted for FFI" when users compile their
programs - a solution that doesn't require that would be much better.
* We don't want to simply zero all memory when it is collected, for
performance reasons.

A possible solution to the bad things:

* A Pony type could be annotated as containing sensitive data.
* The runtime could then automatically zero the contents of collected
sensitive objects, without needing to write a finaliser.
* More hypothetically, it might also be interesting to use the type system
to determine when a behaviour uses transient sensitive objects, or drops
references to non-transient sensitive objects, and infer the need for a GC
pass (either at behaviour completion, or during the behaviour).

I hope some portion of that is useful to you!


On 8 October 2015 at 09:23, rmeijer <rmeijer-qWit8jRvyhVmR6Xm/[email protected]> wrote:

> Working on software that handles sparse capabilities, I keep running into
> the issue that the desire to write maximally robust code and the desire to
> maximize the volatility of sensitive data seem to be mutually exclusive to
> the extreme. 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.
> Doing the same with Python, the results differ and sometimes a sparse cap
> could linger in process memory hours after outliving its functional need
> from the programs perspective. While I haven't ported anything to for
> example Java or Javascript, I imagine given the apparent similarities in
> the design of such runtimes, the results would likely be similar for those
> languages. In fact, I would expect these languages to be worse given
> Python's reference counting based GC and that was the main reason I picked
> Python as first language to port to.
>
> I dislike the idea of memory insecurity. But I dislike the idea of
> powerful tokens of authority lingering in process memory for hours or more
> even more. So if I'dd need to choose at the moment it would be hard, but I
> guess I'dd go with the maximum volatility at the price of memory
> insecurity. I'dd still would rather have seen I didn't have to choose
> between two evils though. But for all practical purposes, the two desired
> properties seem to be mutually exclusive.
>
> Would these all be valid assertions? Or am I jumping to conclusions here?
> And if it is a valid assertion, are memory safety and sensitive data
> volatility mutually exclusive in a "fundamental" way? Or would it for
> example be possible to create a memory safe or even capability secure
> programming language that supports sensitive-data volatility?
>
>
> Rob
> _______________________________________________
> cap-talk mailing list
> [email protected]
> http://www.eros-os.org/mailman/listinfo/cap-talk
>

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