| 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
| ||
|
Message-ID: <486C4CC5.2060006@hitachi.com>
Date: Thu, 03 Jul 2008 12:51:33 +0900
From: Hidehiro Kawai <hidehiro.kawai.ez@...achi.com>
To: Michael Kerrisk <mtk.manpages@...glemail.com>
Cc: Philippe De Muyter <phdm@...qel.be>,
Michael Kerrisk <mtk.manpages@...il.com>,
linux-kernel@...r.kernel.org,
libdc1394-devel@...ts.sourceforge.net, stefanr@...6.in-berlin.de,
sugita <yumiko.sugita.yf@...achi.com>,
Satoshi OSHIMA <satoshi.oshima.fk@...achi.com>
Subject: Re: mmap'ed memory in core files ?
Hi,
Michael Kerrisk wrote:
> [CC+= hidehiro.kawai.ez@...achi.com]
>
> 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:
>>
>>>On 7/1/08, Philippe De Muyter <phdm@...qel.be> wrote:
>>>
>>>>Hello everybody,
>>>>
>>>> I develop video acquisition software using the video1394 interface.
>>>> The images grabbed by the camera and iee1394 bus are kept in kernel
>>>> memory and made available to the user program through a mmap call done
>>>> in the libdc1394 library :
>>>>
>>>> dma_ring_buffer= mmap(0, vmmap.nb_buffers * vmmap.buf_size,
>>>> PROT_READ|PROT_WRITE,MAP_SHARED, craw->capture.dma_fd, 0);
>>>>
>>>> Sometimes, my program crashes and produces a core file :) It seems to
>>>> me that the core file does not contain the mmap'ed memory and hence
>>>> I cannot replay my program with the same image for debugging purpose.
>>>>
>>>> Is it possible to configure the kernel through /proc, or through the mmap
>>>> system call to have that mmapped segment in the core file, or do I need
>>>> to modify the kernel itself to obtain the behaviour I want ? If I
>>>> need to modify the kernel, can some kind soul provide me some pointers ?
>>>
>>>
>>>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.
>>
>>Is that a design decision, or a mere finding of the way it is implemented
>>now ?
MMIO pages have been not dumped since a long time ago, and I didn't target
them for the coredump_filter feature because I thought it was generally
danger to read MMIO pages. As for frame buffer we would be able to
safely access to it, but there is no way to tell it from other MMIO
mappings, AFAIK.
>>So, back to my original question :
>>
>>Can some kind soul provide me some pointers to the way I should modify
>>the kernel to make the inclusion of the video1394 mmapped segment in
>>core files possible ?
>
>
> Perhaps Hidehiro, who wrote the coredump_filter feature, can provide insight.
The following patch may help. To dump MMIO pages, set bit 5 of
coredump_filter.
$ echo 0x23 > /proc/<PID>/coredump_filter
Signed-off-by: Hidehiro Kawai <hidehiro.kawai.ez@...achi.com>
---
This patch is not intended to be merged to the upstream kernel
because the safeness of reading VM_IO mappings has not been
proved.
Index: linux-2.6.26-rc5-mm3/fs/binfmt_elf.c
===================================================================
--- linux-2.6.26-rc5-mm3.orig/fs/binfmt_elf.c
+++ linux-2.6.26-rc5-mm3/fs/binfmt_elf.c
@@ -1141,11 +1141,18 @@ static unsigned long vma_dump_size(struc
if (vma->vm_flags & VM_ALWAYSDUMP)
goto whole;
- /* Do not dump I/O mapped devices or special mappings */
- if (vma->vm_flags & (VM_IO | VM_RESERVED))
+#define FILTER(type) (mm_flags & (1UL << MMF_DUMP_##type))
+
+ /* By default, do not dump memory mapped I/O mappings */
+ if (vma->vm_flags & VM_IO) {
+ if (FILTER(MMIO))
+ goto whole;
return 0;
+ }
-#define FILTER(type) (mm_flags & (1UL << MMF_DUMP_##type))
+ /* Do not dump special mappings */
+ if (vma->vm_flags & VM_RESERVED)
+ return 0;
/* By default, dump shared memory if mapped from an anonymous file. */
if (vma->vm_flags & VM_SHARED) {
Index: linux-2.6.26-rc5-mm3/include/linux/sched.h
===================================================================
--- linux-2.6.26-rc5-mm3.orig/include/linux/sched.h
+++ linux-2.6.26-rc5-mm3/include/linux/sched.h
@@ -403,8 +403,9 @@ extern int get_dumpable(struct mm_struct
#define MMF_DUMP_MAPPED_PRIVATE 4
#define MMF_DUMP_MAPPED_SHARED 5
#define MMF_DUMP_ELF_HEADERS 6
+#define MMF_DUMP_MMIO 7
#define MMF_DUMP_FILTER_SHIFT MMF_DUMPABLE_BITS
-#define MMF_DUMP_FILTER_BITS 5
+#define MMF_DUMP_FILTER_BITS 6
#define MMF_DUMP_FILTER_MASK \
(((1 << MMF_DUMP_FILTER_BITS) - 1) << MMF_DUMP_FILTER_SHIFT)
#define MMF_DUMP_FILTER_DEFAULT \
Regards,
--
Hidehiro Kawai
Hitachi, Systems Development Laboratory
Linux Technology Center
--
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/
Powered by blists - more mailing lists