linux-kernel - Re: mmap'ed memory in core files ?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 02 Jul 2008 14:24:59 +0200
From:	Stefan Richter <stefanr@...6.in-berlin.de>
To:	Philippe De Muyter <phdm@...qel.be>
CC:	Michael Kerrisk <mtk.manpages@...glemail.com>,
	Michael Kerrisk <mtk.manpages@...il.com>,
	linux-kernel@...r.kernel.org,
	libdc1394-devel@...ts.sourceforge.net,
	hidehiro.kawai.ez@...achi.com,
	linux1394-devel@...ts.sourceforge.net
Subject: Re: mmap'ed memory in core files ?

>> On Wed, Jul 2, 2008 at 12:50 PM, Philippe De Muyter <phdm@...qel.be> wrote:
>>> Hi Michael,
>>>
>>> On Tue, Jul 01, 2008 at 08:16:11PM +0200, Michael Kerrisk wrote:
>>>> Have a look at the section "Controlling which mappings are written to
>>>> the core dump" in a recent core.5 man page:
>>>> http://www.kernel.org/doc/man-pages/online/pages/man5/core.5.html
>>> thanks for the info.  I didn't know about /proc/PID/coredump_filter.
>>>
>>> that part was promising :
>>>
>>>       bit 2  Dump file-backed private mappings.
>>>       bit 3  Dump file-backed shared mappings.
>>>
>>>    The default value of coredump_filter is 0x3; this reflects traditional
>>>    Linux behavior and means that only anonymous memory segments are dumped.
>>>
>>> Unfortunately, the part that applies to me (I have tested it) is the next one :
>>>
>>>    Memory-mapped I/O pages such as frame buffer are never dumped, [...],
>>>    regardless of the coredump_filter value.

This shouldn't be a problem to you as far as I understand.  I suppose 
"memory mapped I/O pages" means registers of PCI devices, mapped into 
the memory address space.

The DMA buffer which you would like to get included in the core file is 
normal RAM (I suppose: allocated by the kernel in the kernel's virtual 
address space, mapped into the application client's address space by 
mmap(), and also mapped into the FireWire controller's local bus address 
space for it to write received data into).

FireWire controllers also have memory-mapped I/O regions (per OHCI: at 
least one region of at least 2048 bytes size).  But your process never 
accesses them, only the kernel drivers do (to start and stop DMA 
programs and so on --- while the DMA programs and the DMA data buffers 
live in normal RAM).
-- 
Stefan Richter
-=====-==--- -=== ---=-
http://arcgraph.de/sr/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/