linux-kernel - Re: [PATCH] x86: access to efi reserved memory type

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]

Date:	Mon, 9 Mar 2009 08:16:56 -0500
From:	Robin Holt <holt@....com>
To:	"H. Peter Anvin" <hpa@...or.com>
Cc:	Cliff Wickman <cpw@....com>, linux-kernel@...r.kernel.org,
	mingo@...e.hu
Subject: Re: [PATCH] x86: access to efi reserved memory type

On Sun, Mar 08, 2009 at 03:51:20PM -0700, H. Peter Anvin wrote:
> Cliff Wickman wrote:
...
> > The walk() function scans the EFI memory map and does a callback to a
> > specified function for each memory area of a specified type.
> > efi_memmap_walk_reserved() provides a scan for type EFI_RESERVED_TYPE.
> >  (an earlier version of this patch had proposed a new EFI type, but
> >   EFI_RESERVED_TYPE should be sufficient, given that the firmware follows
> >   the standard and does not use such memory for its own purposes)
...
> In particular, I really want to know why a plain platform device is
> insufficient, and look for a better solution than this, using the
> generic memory map interfaces rather than something EFI-specific.

For the driver Cliff is referring to, we are attempting to provide EFI
reserved memory to a special hardware (drivers/misc/sgi-gru) device
which is capable of handling pages up to 1TB in size.  Additionally, a
previously posted xpmem driver could make those pages available via
Numalink to other SSIs connected to the same fabric.

Excuse my ignorance, but what do you mean by a "plain platform device"?
By generic memory map interfaces, are you proposing we use order based
allocations?  If so, how do you propose we zero these 1TB (worst case)
size pages.  Our current estimate is this will take approx 20 minutes,
but newer processors might shorten that.  What assurances can we get on
these large pages not getting fragmented and therefore becoming useless
and requiring a reboot to reclaim.

I believe we have a special case of memory needing to be reserved by
BIOS, passed to a special driver which can utilize the GRU for async
zero on allocation and to prevent unintended fragmentation.  I agree we
probably made a small mistake in our submission in that the patch set
which adds the EFI walk should have included the special purpose driver.
We will work to correct that.

Thanks,
Robin
--
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/