linux-kernel - Re: [PATCH] vmcore: call remap_pfn_range() separately for respective partial pages

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: <20131203151247.GD4251@redhat.com>
Date:	Tue, 3 Dec 2013 10:12:47 -0500
From:	Vivek Goyal <vgoyal@...hat.com>
To:	HATAYAMA Daisuke <d.hatayama@...fujitsu.com>
Cc:	"Eric W. Biederman" <ebiederm@...ssion.com>,
	Atsushi Kumagai <kumagai-atsushi@....nes.nec.co.jp>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	"kexec@...ts.infradead.org" <kexec@...ts.infradead.org>
Subject: Re: [PATCH] vmcore: call remap_pfn_range() separately for respective
 partial pages

On Tue, Dec 03, 2013 at 02:16:35PM +0900, HATAYAMA Daisuke wrote:

[..]
> >Even if copying partial pages into the 2nd kernel, we need to use ioremap()
> >once on them, and I think the ioremap() is exactly similar to
> >remap_pfn_range() for a single page. There seems no difference on safeness
> >between them.
> >
> 
> I suspected some kind of pre-fetching could be performed when just page table
> is created. But it's common thing between the two cases above. Then, as you say,
> it would be safer to read less data from non-System-RAM area. Copying seems
> better in our case.

If we map page and just read *only* those bytes as advertized by ELF
headers and fill rest of the bytes with zero, I think that seems like
a right thing to do. We are only accessing what has been exported by
ELF headers and not trying to read outside that range.

> 
> Another concern to reading data from partial pages is a possibility of
> undesirable hardware prefetch to non-System-RAM area. Is it better to disable this?

If it becomes an issue, may be. I think we can fix it when we run into
an actual issue.

> 
> >Also, current /proc/vmcore shows user-land tools a shape with holes not
> >filled with zeros both in case of read() and in case of mmap(). If we adapt
> >copying one without reading data in holes, shape of /proc/vmcore gets
> >changed again.
> >
> 
> So, next patch will change data in holes by filling them with zeros.
> 
> BTW, we have now page cache interface implemented by Michael Holzheu, but
> we have yet to use it on x86 because we've never wanted it so far. It's
> natural to use it to read partial pages on-demand, but I also in part think
> that it's not proper time to start using new mechanism that needs to be tested
> more. How do you think?

Do we gain anything significant by using that interface. To me it looks
like this will just delay creation of mapping for partial pages. Does not
save us any memory in second kernel?

I would think that in first pass, keep it simple. Copy partial pages in
second kernel's memory. Read data as exported by ELF headers. Fill rest
of the page with zeros. Adjust /proc/vmcore ELF headers accordingly and
that should do it.

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/