linux-kernel - Re: [PATCH] kdump, oldmem: support mmap on /dev/oldmem

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: <20130207150623.GC6462@redhat.com>
Date:	Thu, 7 Feb 2013 10:06:23 -0500
From:	Vivek Goyal <vgoyal@...hat.com>
To:	"Hatayama, Daisuke" <d.hatayama@...fujitsu.com>
Cc:	"ebiederm@...ssion.com" <ebiederm@...ssion.com>,
	"cpw@....com" <cpw@....com>,
	"kumagai-atsushi@....nes.nec.co.jp" 
	<kumagai-atsushi@....nes.nec.co.jp>,
	"lisa.mitchell@...com" <lisa.mitchell@...com>,
	"kexec@...ts.infradead.org" <kexec@...ts.infradead.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] kdump, oldmem: support mmap on /dev/oldmem

On Wed, Feb 06, 2013 at 07:24:46AM +0000, Hatayama, Daisuke wrote:
> From: Vivek Goyal <vgoyal@...hat.com>
> Subject: Re: [PATCH] kdump, oldmem: support mmap on /dev/oldmem
> Date: Tue, 5 Feb 2013 10:12:56 -0500
> 
> > On Mon, Feb 04, 2013 at 04:59:35AM +0000, Hatayama, Daisuke wrote:
> 
> > [..]
> >> For design decision, I didn't support mmap() on /proc/vmcore because
> >> it abstracts old memory as ELF format, so there's range consequtive on
> >> /proc/vmcore but not consequtive on the actual old memory. For
> >> example, consider ELF headers on the 2nd kernel and the note objects,
> >> memory chunks corresponding to PT_LOAD entries on the first kernel.
> >> They are not consequtive on the old memory. So reampping them so
> >> /proc/vmcore appears consequtive using existing remap_pfn_range() needs
> >> some complicated work.
> > 
> > Can't we call remap_pfn_range() multiple times. Once for each sequential
> > range of memory. /proc/vmcore already has list of contiguous memory areas.
> > So we can parse user passed file offset and size and map into respective
> > physical chunks and call rempa_pfn_range() on all these chunks.
> > 
> > I think supporting mmap() both on /dev/oldmem as well as /proc/vmcore will
> > be nice.
> > 
> > Agreed that supporting mmap() on /proc/vmcore is more work as compared to
> > /dev/oldmem but should be doable.
> > 
> 
> The complication to support mmap() on /proc/vmcore lies in kdump
> side. Objects exported from /proc/vmcore needs to be page-size aligned
> on /proc/vmcore. This comes from the restriction of mmap() that
> requires user-space address and physical address to be page-size
> aligned.
> 
> As I said in the description, objects implicitly referened by
> /proc/vmcore are
> 
>   - ELF headers,
>   - NOTE objects (NT_PRSTATUS entries x cpus, VMCOREINFO), and
>   - memory chunks x (the number of PT_LOAD entries).
> 
> Note objects are scattered on old memory. They are exported as a
> single NOTE entry from program headers, so they need to be gathered at
> the same location in the 2nd kernel starting from the page-size
> aligned address.
> 
> VMCOREINFO is about 1.5KB on 2.6.32 kernel. One NT_PRSTATUS is 355
> bytes. Recent limit of NR_CPUS is 5120 on x86_64. So less than about 2
> MB is enough even on the worst case.
> 
> Note that the format of /proc/vmcore need to change since offset of
> each object need to be page-size aligned.

Ok, got it. So everything needs to be page aligned and if size is not
sufficient then we need a way to pad memory areas to make next object
page aligned. 

To begin with supporting mmap on /dev/oldmem is fine with me. Once that
gets in, it will be good to look at how to make all the individual items
page aligned  so that mmap can be supported on /proc/vmcore.

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/