985758 - Block off the lower and upper 4GB on 64-bit platforms with non-mapped guard pages for greater null-deref (even null-deref by array index) safety

Status: NEW

(Core :: XPCOM, defect)

Description

[Jeff Walden [:Waldo]]

It has recently come to my attention that Safari on OS X uses the whole lower 4GB of address space (and upper, too, for reasons that are somewhat less clear -- maybe indexing with potentially-negative intptr_t or something) as a big guard page.  Thus any null dereference that doesn't escape 4GB -- even if it's an array dereference -- is spectacularly unlikely to do anything but crash immediately, and safely.  We should do this too on 64-bit platforms.

Unfortunately we don't ship 64-bit on Windows, so the vast majority of our users can't benefit from this trick.  But Linux and OS X at least can null-deref-crash more safely.

Comment 1

[(no longer active)]

That sounds like a great idea to me.  We will ship on Win64 as well at some point, at which point all of our desktop users can enjoy the benefits here.

Comment 2

[(Away)]

I agree that this is a good idea for Win64 as well, but keep an eye out for the performance impact. This may cause rebasing of DLLs that would normally want to be <4GB.

Comment 3

[Jeff Walden [:Waldo]]

There's a claim that every 64-bit app on OS X has these memory bits blocked out, and you can't opt out of it.  So this might be a Linux-only bug, then, until Win64 is a thing we care about.

Comment 4

[Chris Peterson [:cpeterson]]

Nicholas, is this feature interesting for Project Uptime? It may help us catch some null deref crashes more reliably and better cluster their crash reports.

We now ship Firefox for Win64 (about 3% of Windows Firefox users), so this bug is no longer Linux-only.

Comment 5

[Masatoshi Kimura [:emk]]

FYI /HIGHENTROPYVA will prefer >4GB address on Windows.

https://blogs.technet.microsoft.com/srd/2013/12/11/software-defense-mitigating-common-exploitation-techniques/

Comment 6

[Nicholas Nethercote [inactive]]

(In reply to Chris Peterson [:cpeterson] from comment #4)
> Nicholas, is this feature interesting for Project Uptime? It may help us
> catch some null deref crashes more reliably and better cluster their crash
> reports.

I can see how it would help some null derefs -- those involving large offsets -- to crash more reliably. I don't see how it would affect crash clustering. So it sounds like it could be a slight improvement, but not a big deal.

Comment 7

[Chris Peterson [:cpeterson]]

(In reply to Masatoshi Kimura [:emk] from comment #5)
> FYI /HIGHENTROPYVA will prefer >4GB address on Windows.
> 
> https://blogs.technet.microsoft.com/srd/2013/12/11/software-defense-
> mitigating-common-exploitation-techniques/

The page says the "/HIGHENTROPYVA linker flag ... is enabled by default for native applications when building with Visual Studio 2012 and beyond." So the lower 4GB part of this bug is apparently fixed for Win64.