Feedback on shared string table

[Shu-yu Guo]

Hi all,

I've been prototyping concurrent structs, and it has pointed out sharing a string table is likely the most maintainable way forward for sharing interned strings.

Here's a design doc, with some holes still left to be filled. Feedback appreciated, especially from leszeks@ and solanes@ for their string expertise, and mlippautz@ for GC expertise.

Cheers,

shu

[Eric Rannaud]

Hi,

I apologize if this is a dumb question:

Would this mean it would become easier for an attacker who has gained some control over a single Isolate to access the content of certain strings coming from other Isolates? (either by somehow iterating over all strings in the shared string table, or less usefully, by testing -- directly or via timing -- whether some particular string value already exists in the shared table because it was previously added by another Isolate -- say, to rapidly test for possible password values that may exist in other isolates).

Or is there some kind of access control that ensures that an Isolate is only able to read strings it is entitled to? Or something else I just don't know anything about?

Thanks for humoring me,

Eric

--
--
v8-dev mailing list
v8-...@googlegroups.com
http://groups.google.com/group/v8-dev
---
You received this message because you are subscribed to the Google Groups "v8-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to v8-dev+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/v8-dev/CAN-e9e_5GC6oS30%3DMmo0ByciK79aHVWD%3DBndXUBmNs_F%2BC00hw%40mail.gmail.com.

[Shu-yu Guo]

Hi Eric,

Sorry for belated reply.

The timing attack in particular seems unlikely to me. The string table is for storing internalized (a better name would be "canonicalized", as in deduplicated) strings only, like property names and other known strings, so they can be compared fast using pointer equality. Sensitive string payloads like passwords (or payloads in general) aren't internalized.

As for the general question of new attack surface, I suppose timing would be possible, but I'm not sure what security problem this poses, if any. It could leak some bits e.g. a certain string was used as a property name on some thread in the process.

As for access control, the short version is there is no access control planned that ensures an Isolate is only able to read strings it is entitled to other than the process boundary. It seems like the threat model you have in mind is one Isolate is already pwned, and you're wondering if it can get to worker thread Isolates' strings. If the pwned Isolate can execute arbitrary code and can discover the location of the other worker thread Isolates' strings, the answer is yes. Worker threads are still in the same process, and without a process boundary you don't get that many guarantees.

Cheers,

shu

To view this discussion on the web visit https://groups.google.com/d/msgid/v8-dev/CA%2BzRj8Ude2S%3DheqH4WywiRnW1Y9A7y8jFFbSEP6G2R1OWv9rtg%40mail.gmail.com.