Hi again, The enabling of PHC on Linux64 Nightly builds went smoothly, so I just enabled it for Win64 Nightly builds (bug 1569864). This will increase the number of users by roughly 10x.
If you have minidump access on crash-stats you can search for PHC crash reports by searching for the presence of the `phc kind` field. The `phc alloc stack` and `phc free stack` fields currently are not auto-symbolicated; Christian Holler has a script that can do the symbolication. Nick On Fri, 19 Jul 2019 at 13:32, Nicholas Nethercote <n.netherc...@gmail.com> wrote: > Greetings, > > PHC is a probabilistic heap checker I have been working on. It has landed > and I am planning to enable it on Monday morning AEST (which is Sunday > afternoon/evening in many parts of the world). For now it will only be > enabled on Linux64 Nightly builds (and also local developer builds) but I > hope to also enable it on Win64 Nightly builds soon. > > Here is a short description of PHC that comes from the comment at the top > of memory/replace/phc/PHC.cpp: > > // PHC is a probabilistic heap checker. A tiny fraction of randomly chosen > heap > // allocations are subject to some expensive checking via the use of OS > page > // access protection. A failed check triggers a crash, whereupon useful > // information about the failure is put into the crash report. The cost and > // coverage for each user is minimal, but spread over the entire user base > the > // coverage becomes significant. > > I have included the rest of that comment, which describes the > implementation in more detail, at the bottom of this email. Also see bug > 1523276 <https://bugzilla.mozilla.org/show_bug.cgi?id=1523276> for > additional details. > > This is a tool that will hopefully detect use-after-free errors in the > wild. It is a somewhat complex wrapper of our heap allocator, and > everything depends on the heap allocator. This means that any bugs in PHC > have the potential to cause a wide variety of problems. Please keep an eye > out for any such problems. It's hard to say exactly what those problems > might be... during testing I saw and fixed some deadlocks and some crashes > within arena_dalloc(), but other effects may be possible. Also, it's > completely non-deterministic (by design) which further complicates the > detection of problems. > > Please let me know if you have any questions or concerns. > > Nick > > > // The idea comes from Chromium, where it is called GWP-ASAN. (Firefox > uses PHC > // as the name because GWP-ASAN is long, awkward, and doesn't have any > // particular meaning.) > // > // In the current implementation up to 64 allocations per process can > become > // PHC allocations. These allocations must be page-sized or smaller. Each > PHC > // allocation gets its own page, and when the allocation is freed its page > is > // marked inaccessible until the page is reused for another allocation. > This > // means that a use-after-free defect (which includes double-frees) will be > // caught if the use occurs before the page is reused for another > allocation. > // The crash report will contain stack traces for the allocation site, the > free > // site, and the use-after-free site, which is often enough to diagnose the > // defect. > // > // The design space for the randomization strategy is large. The current > // implementation has a large random delay before it starts operating, and > a > // small random delay between each PHC allocation attempt. Each freed PHC > // allocation is quarantined for a medium random delay before being > reused, in > // order to increase the chance of catching UAFs. > // > // The basic cost of PHC's operation is as follows. > // > // - The memory cost is 64 * 4 KiB = 256 KiB per process (assuming 4 KiB > // pages) plus some metadata (including stack traces) for each page. > // > // - Every allocation requires a size check and a decrement-and-check of an > // atomic counter. When the counter reaches zero a PHC allocation can > occur, > // which involves marking a page as accessible and getting a stack trace > for > // the allocation site. Otherwise, mozjemalloc performs the allocation. > // > // - Every deallocation requires a range check on the pointer to see if it > // involves a PHC allocation. (The choice to only do PHC allocations > that are > // a page or smaller enables this range check, because the 64 pages are > // contiguous. Allowing larger allocations would make this more > complicated, > // and we definitely don't want something as slow as a hash table lookup > on > // every deallocation.) PHC deallocations involve marking a page as > // inaccessible and getting a stack trace for the deallocation site. > // > // In the future, we may add guard pages between the used pages in order > // to detect buffer overflows/underflows. This would change the memory > cost to > // (64 * 2 + 1) * 4 KiB = 516 KiB per process and complicate the machinery > // somewhat. > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
