3 ms·
If you're going to modify the processor to add a feature to prevent speculative reads from the same address space when you control the JIT, why not add an instr
by reitzensteinm 8y ago
If you're going to modify the processor to add a feature to prevent speculative reads from the same address space when you control the JIT, why not add an instruction that enters a mode that passes the address of all reads and writes through an implicit mask until it has been switched off.
This would outright prevent code generated by the JIT to do out of bounds speculative loads directly, it would just load a rewritten address from within the restricted region. Instead you'd have to trick an API call (which would be executed without the restriction) in to doing it for you.
- doctorpangloss 8y agoWhy not create a chip that accelerates compilation? Or like those old Java cores on phones, accelerates the web browser's parsing, compilation and code execution needs? We already ship H.264 decoders on everything. And vendors are sort of settling on, Chrome/WebKit rules all. Why not just standardize the model in the hardware? On the other hand, image and video codecs are actually chock full of security issues nobody bothers to exploit.
- monocasa 8y agoHardware isn't magical go faster juice. Doing compilation 'in hardware' isn't any faster than doing it in software.
- verall 8y agoVideo processing is generally a parallel bandwidth-heavy task with predictable memory access patterns whereas compilation is NOT. Thus video processing lends well to hardware implementations. Additionally everything h.265/VP8 or later was designed with people from HW companies on the committees and thus the algorithms were adjusted specifically to benefit HW impl. Compilation is extremely configurable, Chrome wants to push out updates to its JS parser every month, there are like a million reasons this isnt done in hardware.