5 ms·
According to https://static.googleusercontent.com/media/research.google.com/en//pubs/archive/35649.pdf https://static.googleusercontent.com/media/research.googl
by roca 9y ago
According to https://static.googleusercontent.com/media/research.google.com/en//pubs/archive/35649.pdf https://static.googleusercontent.com/media/research.google.c... NaCl does not sandbox loads, relying on address-space separation to ensure secret data is not leaked. Obviously this only works with a single sandboxed application per address space. (And even then you'd have to be pretty careful!)
- fpoling 9y agoThis is only for NaCl on ARM or AMD64. The original NaCl for x86 uses the segment registers for isolation allowing to restrict both loads and stores only to the permitted addresses. That, as far as I understand, does allow to embed into 32-bit process without compromising secretes. So as a speculation in an alternative world where Google has not developed Pepper, but bridged web api into x86 NaCl, the latter designs for x64 and ARM would restrict loads only from the allowed address space.
- roca 9y agohttps://static.googleusercontent.com/media/research.google.com/en//pubs/archive/34913.pdf https://static.googleusercontent.com/media/research.google.c... shows that the original NaCl-x86 only allowed one sandboxed application per process. So to support pages with more than one plugin, IPC would have been needed. Sure, (P)NaCl could have been implemented differently in a way that allowed multiple sandboxed applications per process, and then DOM access would have been easier and maybe Pepper wouldn't have been necessary, though there would have been slightly higher overhead I guess. That's all history now.