1663983 - Identify / disambiguate crashes caused by guard page accesses

Status: RESOLVED FIXED

(Core :: Memory Allocator, enhancement)

Description

[Gian-Carlo Pascutto [:gcp]]

We currently have trailing guard pages on normal and large jemalloc allocations (see e.g. https://bugzilla.mozilla.org/show_bug.cgi?id=1446040).

This means that any crash where we have a read/write at a 1M-4K to 1M offset inside the heap is something hitting the guard pages. Such crashes identify potential security bugs.

We should probably find out a way to find and dig them out of Socorro data - currently we don't do anything with this.

One complexity is that large allocations (>=1M) don't have a guard page in the middle, so just going by offset might include other bugs.

David Major explained me that PHC identifies PHC violations by hooking the crash reporter and querying whether a crash is in a PHC page. I don't see why we wouldn't be able to do the same with jemalloc and check if it was a guard page.

Comment 1

[Gian-Carlo Pascutto [:gcp]]

glandium, njn, can you comment on whether what I'm saying sounds sensible enough?

Comment 2

[Nicholas Nethercote [inactive]]

The idea seems reasonable. Here is the crash reporter hooking code. Here is another relevant location for Linux; other platforms are similar. From those two locations you can follow the plumbing around to get the idea.

Comment 3

[Mike Hommey [:glandium]]

Implementation-wise, I'd go with adding an enum value for guard pages to PtrInfoTag in mozjemalloc_types.h and make jemalloc_ptr_info be able to handle them. It would be nice to make the PHC part rely on jemalloc_ptr_info too, but that be a lot of extra work (and would require a lot more thought to make it fit in the replace-malloc scheme).

Comment 4

[Alex Franchuk [:afranchuk]]

It seems like this functionality can be integrated into rust-minidump infrastructure fairly easily. We can just look at the memory maps to determine likely guard pages (1 page in size, no permissions). While this wouldn't be getting explicit information from the memory allocator, it's likely to be fairly accurate as no-permission pages are often used for this purpose alone. This also has the benefit of being a more general solution that could flag other buffer overruns which use guard pages as a safety measure.

In minidump-processor, we already have all the memory map information available, so finding likely guard pages and adding a flag for cases where an invalid memory access was in a guard page is a small effort, likely no more than 8 hours of work.

Comment 5

[Alex Franchuk [:afranchuk]]

Attachment: pr 829: Bug 1663983 - Check for memory accesses to likely guard pages.

Comment 6

[Alex Franchuk [:afranchuk]]

:gcp, this is merged in minidump-processor and exposed in the JSON output. We may want to keep this bug open to cover Socorro changes, or we may want to open a new, more specific one. Let me know what you'd like.

Comment 7

[Gian-Carlo Pascutto [:gcp]]

I think it's best to open a new bug in the right product.

Comment 8

[Alex Franchuk [:afranchuk]]

Bug 1830954 covers the Socorro implementation.