Sam Tobin-Hochstadt wrote:
However, I think this demonstration makes a much stronger case against
conservative GC. Dion's attack requires, fundamentally, three things:
1. Conservative GC (of any form).
2. Some data structure that the browser holds weakly if at all, but
can be held strongly from JS.
3. Some way to tell if that data is collected.
I think that there's no way to eliminate 2& 3 from the browser. For
example, 2 could be a large array, and 3 could be a `currentMemoryUse`
function (which doesn't currently exist, but might).
Such a currentMemoryUse function would not be easy to standardize, just
on interop and complexity of implementation grounds, if not on the
"liveness channel" attack.
But you are right in general: Dion tried a weakmap timing channel
attack, since SpiderMonkey's WeakMap is based on doubling a HashMap when
it fills to a certain load factor. However, he couldn't get that attack
to work.
These channels may be noisy. The problem with weak refs with prompt
notification, or enumerable weakmap, is that those leak much more
precise liveness info.
Security is always like this, a set of cross-cutting (non-modular)
properties -- safety properties in Fred Schneider's formulation
(predicates over all future program states). So I don't see how we can
look at conservative GC with an evil eye but not look at other parts of
the system.
Let's say we ban conservative GC as part of ECMA-262's normative
language. We still have interop and capability or "authority" problems
with enumerable weakmaps. Those are not concerns only for SES.
I agree conservative GC makes the system more vulnerable, since (2)
happens (even if under the hood, but in ES6 code "above the hood"), and
(3) is an endless stream of weaknesses and hard-to-close channels.
/be
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
