linux-kernel - Re: [Xen-devel] [PATCH 06/13] xen: detect pre-allocated memory interfering with e820 map

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: <54EDDB2F.6050601@citrix.com>
Date:	Wed, 25 Feb 2015 14:24:47 +0000
From:	David Vrabel <david.vrabel@...rix.com>
To:	Juergen Gross <jgross@...e.com>, <linux-kernel@...r.kernel.org>,
	<xen-devel@...ts.xensource.com>, <konrad.wilk@...cle.com>,
	<david.vrabel@...rix.com>, <boris.ostrovsky@...cle.com>
Subject: Re: [Xen-devel] [PATCH 06/13] xen: detect pre-allocated memory interfering
 with e820 map

On 24/02/15 06:27, Juergen Gross wrote:
> On 02/19/2015 07:07 PM, David Vrabel wrote:
>> On 18/02/2015 06:51, Juergen Gross wrote:
>>> +{
>>> +    unsigned long pfn;
>>> +    unsigned long area_start, area_end;
>>> +    unsigned i;
>>> +
>>> +    for (i = 0; i < XEN_N_RESERVED_AREAS; i++) {
>>> +
>>> +        if (!xen_reserved_area[i].size)
>>> +            break;
>>> +
>>> +        area_start = PFN_DOWN(xen_reserved_area[i].start);
>>> +        area_end = PFN_UP(xen_reserved_area[i].start +
>>> +                  xen_reserved_area[i].size);
>>> +        if (area_start >= end_pfn || area_end <= start_pfn)
>>> +            continue;
>>> +
>>> +        if (area_start > start_pfn)
>>> +            xen_set_identity_and_remap_chunk(start_pfn, area_start,
>>> +                             released, remapped);
>>> +
>>> +        if (area_end < end_pfn)
>>> +            xen_set_identity_and_remap_chunk(area_end, end_pfn,
>>> +                             released, remapped);
>>> +
>>> +        *remapped += min(area_end, end_pfn) -
>>> +                max(area_start, start_pfn);
>>> +
>>> +        return;
>>
>> Why not defer the whole chunk that conflicts?  Or for that matter defer
>> all this remapping to the last minute.
> 
> There are two problems arising from this:
> 
> - In the initrd case remapping would be deferred too long: the initrd
>   data is still in use when device initialization is running. And we
>   really want the remap to have happened before PCI space is being used.

I'm not sure I understand what you're saying here.

I'm suggesting:

1. Reserve all holes.

2. Relocate (if necessary) all modules (initrd, etc.) to regions that
are RAM in the e820.

3. Rebuild the p2m in RAM.

4. Relocate frames from E820 holes/reserved to the end, free p2m pages
from the holes and replacing them with the read-only 1:1 page (where
possible).

> - Delaying all remapping to the point where the new p2m list is in place
>   would either result in a p2m list with all memory holes covered with
>   individual entries as the new list is built with those holes still
>   populated, ...
>   The first option could easily waste significant amounts of memory (on
>   my test machine with 1TB RAM this would have been about 1GB), while
>   the second option would be performance critical.

I don't understand how this wastes memory.   When you relocate the
frames from the holes you can reclaim the p2m pages for the holes (and
replace them with the r/o mapped identity p2m page).

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