linux-kernel - Re: /proc/vmcore mmap() failure issue

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] [day] [month] [year] [list]

Message-ID: <52942E9B.2030003@jp.fujitsu.com>
Date:	Tue, 26 Nov 2013 14:16:11 +0900
From:	HATAYAMA Daisuke <d.hatayama@...fujitsu.com>
To:	Vivek Goyal <vgoyal@...hat.com>
CC:	Atsushi Kumagai <kumagai-atsushi@....nes.nec.co.jp>,
	"bhe@...hat.com" <bhe@...hat.com>,
	"kexec@...ts.infradead.org" <kexec@...ts.infradead.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"ebiederm@...ssion.com" <ebiederm@...ssion.com>,
	"dyoung@...hat.com" <dyoung@...hat.com>,
	"chaowang@...hat.com" <chaowang@...hat.com>
Subject: Re: /proc/vmcore mmap() failure issue

(2013/11/25 23:41), Vivek Goyal wrote:
> On Mon, Nov 25, 2013 at 06:01:37PM +0900, HATAYAMA Daisuke wrote:
>
> [..]
>>> I agree to avoid this issue by fixing makedumpfile as workaround while to
>>> fix kernel is so tough and risky. However, it sounds strange to me to fix
>>> userspace side elaborately for such definite kernel issue whose cause is
>>> known, so we should fix the kernel itself.
>>>
>>
>>> Otherwise, will you continue to add specific fixes into user tools to
>>> address kernel issues like this case ?
>>>
>>
>> makedumpfile supports a wide range of kernel versions and needs to satisfy
>> backward compatibility. mmap() on /proc/vmcore might be backported to some of
>> the old versions on some distributions if necessary. Then, it's hard to fix
>> each old kernel at each back port. The method that can be applied to all the
>> kernels in general, is necessary.
>>
>> Also, looking at ia64 case where there's boot loader data on partial pages,
>> there could be other environments where partial pages contain other important
>> data other components have. So, the issue depends not only on kernels but also
>> other components such as boot loader and firmwares that can put data on
>> partial pages. We need to get there as long as there's important data there
>> and we have access to there.
>
> Hi Atsushi, Hatayama,
>
> So even if we fix the mmap() issue in kernel, looks like it will be a
> good idea to ship the fix in makedumpfile as there have been a kernel
> release where mmap() will cause issues.
>
> Having said that, I think we need to fix it in kernel also. I was not sure
> that what's the right fix. Should we truncate partial pages or should
> we just copy partial pages from old memory to new kernel's memory and fill
> partial page with zeros. And that's why I was hoping that makedumpfile
> can fill the gap.
>
> Copying partial pages to new memory seems like a safer approach. So may
> be we can take a fix in makeudmpfile and another in kernel.
>
> Hatayama, I know that in the past your initial mmap() patches were copying
> partial pages to new kernel's memory. Would you like to resurrect that
> patch again?
>

(Oh, I yesterday had totally forgotten partial page handling that was dropped
from mmap() patch set in the middle of development...)

Yes, but wait until next week.

-- 
Thanks.
HATAYAMA, Daisuke

--
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/