Repository navigation
Read ELF build ids directly from the target process instead of mmap()ing libraries #71
Description
When populating the module list on Linux we extract the GNU build ID from each executable. To do so we first mmap() the entire file in the process writing the minidump and then extract the data from there. This has a couple of important drawbacks:
- If the file on disk has been deleted we'll get an empty ID, something that we see often in Firefox crashes.
- If the file on disk has been altered we'll get the wrong ID.
- If the file is extremely large
mmap()may fail on 32-bit hosts, we've also seen this happen in 32-bit builds of Firefox.
We could avoid all these issues by reading the ELF headers directly from the process we're dumping. goblin supports parsing an ELF file lazily, though one has to do it manually (see this example).
Activity
jld commentedon Feb 28, 2023
goblin's API is a little suboptimal here;Elf::iter_note_headersseems to expect a&[u8]that starts at the beginning of the file and covers all of thePT_NOTEsegments. But what we really want to do is:Although, if we expect that those will all be close to the start of the file — and in practice they seem to be within the first ~1k — we could just copy in some convenient small amount like 4k (in one syscall, if we have #72), and fall back to larger sizes if we get
goblin::error::Error::Scroll(scroll::error::Error::BadOffset(…)).We'd still want to use that
lazy_parsefeature for that, I think, because there are going to be headers that point to things outside the area we're reading and that we don't care about.gabrielesvelto commentedon Mar 1, 2023
We'd need to fetch some strings from the STRTAB to find the appropriate note, but we could do that lazily and it would require only a handful of extra system calls. The whole STRTAB for libxul.so is ~5MiB in my local build so we could also load it in its entirety if lazy-parsing doesn't work.
gabrielesvelto commentedon Mar 17, 2023
Note: I've experimented with lazy parsing via goblin and it's working just fine.
lissyx commentedon Mar 7, 2024
there's m4b/goblin#391 to fix some of it?
lissyx commentedon Mar 7, 2024
And in fact whole feature is in https://phabricator.services.mozilla.com/D199710
[-]Read ELF build ids directly from the target process instead of mmap()ing it[/-][+]Read ELF build ids directly from the target process instead of mmap()ing libraries[/+]afranchuk commentedon Mar 29, 2024
I'm working on this now (can't assign myself though), based off of https://phabricator.services.mozilla.com/D199710. Though depending on how expensive/slow ptrace PEEKDATA is, it'd still be a lot less memory reading (fewer ptrace calls) to lazy parse ourselves rather than using
goblin(for portions of it, at least).Read ELF build ids directly from the target process.
Read ELF build ids directly from the target process.
Read ELF build ids directly from the target process.
Read ELF build ids directly from the target process. (#112)
Read ELF build ids directly from the target process.