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

Message-ID: <20131125144150.GC21378@redhat.com>
Date:	Mon, 25 Nov 2013 09:41:50 -0500
From:	Vivek Goyal <vgoyal@...hat.com>
To:	HATAYAMA Daisuke <d.hatayama@...fujitsu.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

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?

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