New: Core dumps do not include writable unmodified MAP_PRIVATE maps

Bugme-new Andrew Morton 4 participants 4 messages Jul 17, 2008 1 message not in the archive

Subsystems (3)

Memory management VFS exec and binfmt

lore

Share & tools

lore

Andrew Morton

author maintainer

2008-07-17 20:23 UTC #1 lore raw

In reply to a message not in the archive

(switched to email. Please respond via emailed reply-to-all, not via the bugzilla web interface).

Quoted 36 lines · On Thu, 17 Jul 2008 11:57:08 -0700 (PDT) [email protected] wrote:

http://bugzilla.kernel.org/show_bug.cgi?id=11110
Summary: Core dumps do not include writable unmodified
MAP_PRIVATE maps
Product: Process Management
Version: 2.5
KernelVersion: 2.6.26
Platform: All
OS/Version: Linux
Tree: Mainline
Status: NEW
Severity: normal
Priority: P1
Component: Other
AssignedTo: [email protected]
ReportedBy: [email protected]
CC: [email protected]
Latest working kernel version: Not sure.
Earliest failing kernel version: Been failing at least since April 2006. Passed at some point previous to that, probably 2.4.
Distribution: Debian
Hardware Environment: x86_64 SMP
Software Environment: GDB testsuite
Problem Description:
The test corefile.exp fails because it maps a file and then core dumps, expecting the mapped contents to be in the core dump. The mapping is made with these options:
buf2 = (char *) mmap (0, MAPSIZE, PROT_READ | PROT_WRITE, MAP_PRIVATE, fd,
0);
Any page that has been touched will be dumped, any unmodified page will not be.

Quoted 8 lines

I've discussed this with David Miller a couple of times; last time I recall was in January 2007.
Steps to reproduce:
Run coremaker from the GDB testsuite (attached). Load the core file into GDB
and try to print buf2.

Does anyone recall whether this is deliberate behaviour, or did we just goof?

Thanks.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

Neil Horman

2008-07-17 20:39 UTC #2 lore raw

Quoted 47 lines · Andrew Morton

(switched to email. Please respond via emailed reply-to-all, not via the bugzilla web interface).
Quoted 41 lines · On Thu, 17 Jul 2008 11:57:08 -0700 (PDT) [email protected] wrote:
http://bugzilla.kernel.org/show_bug.cgi?id=11110
Summary: Core dumps do not include writable unmodified
MAP_PRIVATE maps
Product: Process Management
Version: 2.5
KernelVersion: 2.6.26
Platform: All
OS/Version: Linux
Tree: Mainline
Status: NEW
Severity: normal
Priority: P1
Component: Other
AssignedTo: [email protected]
ReportedBy: [email protected]
CC: [email protected]
Latest working kernel version: Not sure.
Earliest failing kernel version: Been failing at least since April 2006. Passed at some point previous to that, probably 2.4.
Distribution: Debian
Hardware Environment: x86_64 SMP
Software Environment: GDB testsuite
Problem Description:
The test corefile.exp fails because it maps a file and then core dumps, expecting the mapped contents to be in the core dump. The mapping is made with these options:
buf2 = (char *) mmap (0, MAPSIZE, PROT_READ | PROT_WRITE, MAP_PRIVATE, fd,
0);
Any page that has been touched will be dumped, any unmodified page will not be.
I've discussed this with David Miller a couple of times; last time I recall was in January 2007.
Steps to reproduce:

Quoted 7 lines

Quoted 3 lines
Run coremaker from the GDB testsuite (attached). Load the core file into GDB
and try to print buf2.
Does anyone recall whether this is deliberate behaviour, or did we just goof?
Thanks.

I'm not 100% sure, and I can see why the kernel might skip over untouched pages, but that seems like a bug to me. The memory is mapped, it should be readable by gdb after a core dump, and since its a mapped file, it can't be assumed to be zero, like heap memory that hasn't been faulted in yet.

Just my $0.02
Neil

Signature · 12 lines

/***************************************************
 *Neil Horman
 *[email protected]
 *gpg keyid: 1024D / 0x92A74FA1
 *http://pgp.mit.edu
 ***************************************************/

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to [email protected].  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

Daniel Jacobowitz

2008-07-17 21:20 UTC #3 lore raw

Quoted 4 lines · Neil Horman

I'm not 100% sure, and I can see why the kernel might skip over untouched pages, but that seems like a bug to me. The memory is mapped, it should be readable by gdb after a core dump, and since its a mapped file, it can't be assumed to be zero, like heap memory that hasn't been faulted in yet.

I'm guessing this is an attempt not to dump shared library text segments. We can't do it solely based on permissions; if I remember right there's a readonly page in the application or ld.so associated with the shared library list that is mprotected to read-only after initialization (-z relro).

In April 2006 Dave M suggested only skipping if VM_EXEC. This will dump some text segment bits (e.g. anything that had a software breakpoint inserted), but not most; writable data is usually written to (at least mostly).

Signature · 8 lines

Daniel Jacobowitz
CodeSourcery

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to [email protected].  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

Roland McGrath

2008-07-17 22:13 UTC #4 lore raw

It is the intended behavior that core dumps usually don't contain copies of unmodified file chunks. If they did, they would include all the text of executables and DSOs, and sometimes be far larger than people want (and take much longer with much more VM and IO load to dump).

It's already the case that dumps do include MAP_PRIVATE vma's with any modified pages. Long ago, the logic did not pay attention to modifiedness and did include all writable vma's.

You can control this now with /proc/pid/coredump_filter. If you want to enhance the logic, like paying attention to VM_EXEC or VM_WRITE, then the thing to do is add more MMF_DUMP_* bits to distinguish more flavors of vma to treat differently. e.g.:

fs/binfmt_elf.c +6 -0

index d48ff5f..0000000 100644  
@@ -1160,6 +1160,12 @@ static unsigned long vma_dump_size(struc
 	if (FILTER(MAPPED_PRIVATE))
 		goto whole;
 
+	if (FILTER(MAPPED_PRIVATE_EXEC) && (vma->vm_flags & VM_EXEC))
+		goto whole;
+
+	if (FILTER(MAPPED_PRIVATE_WRITE) && (vma->vm_flags & VM_WRITE))
+		goto whole;
+
 	/*
 	 * If this looks like the beginning of a DSO or executable mapping,
 	 * check for an ELF header.  If we find one, dump the first page to

Once we have whatever additional options folks are interested in, and play with them for a while, we can think about changing the default setting of MMF_DUMP_FILTER_DEFAULT. (Note that Fedora kernels already change this default to add MMF_DUMP_ELF_HEADERS.)

Thanks,
Roland