[HN Gopher] Control-Flow Integrity in V8
       ___________________________________________________________________
        
       Control-Flow Integrity in V8
        
       Author : unripe_syntax
       Score  : 39 points
       Date   : 2023-10-09 14:55 UTC (8 hours ago)
        
 (HTM) web link (v8.dev)
 (TXT) w3m dump (v8.dev)
        
       | Waterluvian wrote:
       | Reading this got me wondering about the bigger picture trade-off
       | between security and performance.
       | 
       | Is there a reasonable way to estimate how much performance could
       | be gained if we operated in a hypothetical universe where we
       | never ever had to worry about security?
        
         | MailNerd wrote:
         | Most of these techniques are engineered to not cause much of a
         | performance degradation. Otherwise there would not be much
         | uptake. Also they are often implemented in compilers which
         | produce native binaries so the impact is low.
         | 
         | The mitigations for the various hardware sidechannel attacks
         | discovered in the past year have a bit larger impact. But you
         | don't need these at all on your local computer, only in shared
         | environments.
         | 
         | As a rule of thumb each mitigation usually costs a single digit
         | percentage, seldom double digit. Of course in a system multiple
         | mitigations will be at play but the impact should be far below
         | 100%.
         | 
         | The performance impact of scripting languages, interoperable
         | web standards and bad implementations are far worse :)
        
         | a1369209993 wrote:
         | > Is there a reasonable way to estimate how much performance
         | could be gained if we operated in a hypothetical universe where
         | we never ever had to worry about security?
         | 
         | Not really, no. In the limit of a theoretically perfect
         | implementation, the performance overhead of security is zero
         | (except to the extent that you count cryptography, but that's
         | distinct from CFI/RCE/memory-corruption/etc-style security).
         | The practical overhead basically comes from defence-in-depth to
         | insure that imperfect implementation _don 't_ break security,
         | and there's not in general any fundamental reason why
         | imperfection A is common problem that needs to be mitigated,
         | but imperfection B is a stupid corner case deserving of "well,
         | don't do that then". Also we essensially -by-definition don't
         | _have_ a theoretically perfect implementation to compare
         | against, so we can 't even estimate the zero-overhead point
         | with any confidence.
        
         | paulddraper wrote:
         | > how much performance could be gained
         | 
         | One place to look at would be TLS perf.
         | 
         | Network latency, encryption compute.
        
       | Waterluvian wrote:
       | "V8 exploits typically follow a similar pattern: an initial bug
       | leads to memory corruption..."
       | 
       | naturally gets me wondering about Firefox and Rust. Is it
       | measurably helping eliminate this class of issue? Too soon to
       | tell?
        
         | kevingadd wrote:
         | The JS runtime and JIT are still entirely C++ and assembly,
         | afaik. I'm not sure we'd ever see them migrate Spidermonkey to
         | Rust.
        
         | treyd wrote:
         | With jitting runtimes like V8 often the root cause of the
         | exploit is a logical error in code generation that leads to the
         | sandboxed code to get a read/write gadget into memory outside
         | the sandbox. Rewriting the jit in Rust _might_ help eliminate
         | those kinds of issues, but it 's still entirely possible they
         | would happen.
        
         | paulddraper wrote:
         | > Is it measurably helping eliminate this class of issue?
         | 
         | No.
         | 
         | A JIT is a compiler.
         | 
         | The compiler itself would be memory-safe, but not the compiled
         | output.
        
         | hovav wrote:
         | A JIT is a machine for turning logic bugs into memory unsafety.
         | Rewriting a JIT in Rust won't eliminate logic bugs and won't
         | guarantee memory safety for the binary output of the JIT (as
         | distinct from the JIT implementation itself).
        
           | infogulch wrote:
           | Agreed. But the way you put it makes me wonder how many
           | memory safety vulns have been found in JIT implementations
           | (not the machine code they output).
        
           | nextaccountic wrote:
           | Okay, but in this case software verification like with Coq or
           | F* could help
        
             | hovav wrote:
             | Yes! See, e.g., Fraser Brown et al., "Towards a Verified
             | Range Analysis for JavaScript JITs," in proc. PLDI 2020,
             | https://www.cs.utexas.edu/~hovav/dist/vera.pdf
        
       ___________________________________________________________________
       (page generated 2023-10-09 23:02 UTC)