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 On Fri, Jun 25, 2021 at 10:02 PM Eric Rannaud <[email protected]> wrote: > 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 > > On Fri, Jun 25, 2021, 19:50 'Shu-yu Guo' via v8-dev < > [email protected]> wrote: > >> 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 >> <https://docs.google.com/document/d/1BuW8dSd8tVWl-JJEu4pFKuvTB1iiVwD5Ecg_khjOy08/edit?usp=sharing>, >> 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 >> >> -- >> -- >> v8-dev mailing list >> [email protected] >> 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 [email protected]. >> 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 >> <https://groups.google.com/d/msgid/v8-dev/CAN-e9e_5GC6oS30%3DMmo0ByciK79aHVWD%3DBndXUBmNs_F%2BC00hw%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> > -- > -- > v8-dev mailing list > [email protected] > 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 [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/v8-dev/CA%2BzRj8Ude2S%3DheqH4WywiRnW1Y9A7y8jFFbSEP6G2R1OWv9rtg%40mail.gmail.com > <https://groups.google.com/d/msgid/v8-dev/CA%2BzRj8Ude2S%3DheqH4WywiRnW1Y9A7y8jFFbSEP6G2R1OWv9rtg%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- -- v8-dev mailing list [email protected] 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/v8-dev/CAN-e9e-AKonJNaqUgqchkGkVd8tAtH8033omwf3TX0sYP%3DwCsQ%40mail.gmail.com.
