Updates:
Status: New
Comment #9 on issue 2473 by [email protected]:
http://www.chaostoperfection.com/ crashes in V8 initialization on 64-bit
platforms
http://code.google.com/p/v8/issues/detail?id=2473
There are two different things at work here. Reserving an address space
hole is reasonable if you need 32-bit relative addressing. The security
team has already discussed that, and is planning on changing the way this
limit is imposed (probably enforcing it in the allocator only for
committed, contiguous pages). That said, for security reasons we absolutely
need a restriction here because the vast majority of the codebase isn't yet
guaranteed safe against 32-bit integer overflows on 64-bit architectures.
So, this is the only thing preventing a very common buffer overflow pattern.
As for V8's code limit being silently increased to 512mb, I am a bit
disturbed. V8's use of RWX pages for its emitted code has always been a
major security liability. A few years ago we worked with the V8 team to
arrive at a number of mitigations for that liability: JIT size limits,
randomized allocation bases, constant masking, and guard pages. On 64-bit
architectures the size limit should be 128mb, and we were told that the
security team would be consulted before changing these limits in the
future. I should also note that for the fast majority of sites (including
everything in the top 100k) this limit was many times what they would ever
encounter, but we kept it this high for a small minority of uncommon sites
using legacy JSON libraries that triggered excessive JITing. (And for
comparison, IE's JIT has a 16mb limit, and has other mitigations that make
it better than ours on the security front.)
So, from the security perspective we have a serious regression here. Any
thoughts on how to best move forward?
--
v8-dev mailing list
[email protected]
http://groups.google.com/group/v8-dev
