linux-kernel - Re: [edk2] Corrupted EFI region

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]

Date:	Mon, 16 Sep 2013 11:59:20 +0100
From:	Matt Fleming <matt@...sole-pimps.org>
To:	jerry.hoemann@...com
Cc:	Andrew Fish <afish@...le.com>, edk2-devel@...ts.sourceforge.net,
	Laszlo Ersek <lersek@...hat.com>, linux-efi@...r.kernel.org,
	Gleb Natapov <gleb@...hat.com>,
	lkml <linux-kernel@...r.kernel.org>,
	David Woodhouse <dwmw2@...radead.org>,
	Matthew Garrett <mjg59@...f.ucam.org>,
	Brian Richardson <brian.richardson@...el.com>,
	Colin Ian King <colin.king@...onical.com>,
	Randy Wright <rwright@...com>,
	Linn Crosetto <linn.crosetto@...com>, terry.lee@...com,
	samer.el-haj-mahmoud@...com, randy.pawell@...com, chrisp@...com,
	linda.knippers@...com, dong.wei@...com,
	"H. Peter Anvin" <hpa@...or.com>, Borislav Petkov <bp@...en8.de>,
	Josh Triplett <josh@...htriplett.org>
Subject: Re: [edk2] Corrupted EFI region

On Fri, 13 Sep, at 02:38:12PM, jerry.hoemann@...com wrote:
> Matt,
> 
> We have hit an issue on our new platform in development related to the
> call of efi_reserve_boot_services() from setup_arch().
> 
> The reservation can interfere with allocation of the crash kernel.
 
Jerry, thanks for bringing this up.

> In pre 3.9(?) kernels,  the crash kernel is required to be allocated from
> physically contiguous memory below 896 MB.
> 
> Our new platforms are large in both the amount of memory and the amount
> of IO. This requires large crash kernels for kdump to work.  This is even
> after the work done for makedumpfile v 1.5 to allow it to work with a
> smaller foot print.
> 
> 
> One of the problems is that drivers will allocate memory as boot code and/or
> data in the region < 896 that effectively fragments this memory.
> With the reservation, we can't reuse the memory when needed for the
> crash kernels.   If we remove the reservation and allow the kernel
> to reuse the memory,  we the reservation of the crash kernel succeeds.
> 
> This is definitely a problem for distros that are pre 3.9.  Probably less
> so for top of tree, but i haven't been focused there.
> 
> So we are definitely interested in finding a mechanism to not
> do this reservation on platforms that don't have the issues described
> earlier in this thread.

OK, in an ideal world we'd move the crash kernel reservation after
efi_free_boot_services(), because at that point the boot regions are
available again. But it seems that we reserve the boot regions really
early during startup and release them relatively late. The reason is
that the Boot Graphics Resource Table (BGRT) data, if present, is
located in the Boot Services Data regions but we can't extract the
address of the region from the ACPI tables until we've setup the ACPI
subsystem, which happens quite late.

I wonder whether performing the reservation of the crash kernel memory
first, before efi_reserve_boot_services(), would help. That way we'd
only need to reserve remaining regions in efi_reserve_boot_services().
This scheme would rely on nothing writing into the crash kernel area
before we've extracted the BGRT data, however.

-- 
Matt Fleming, Intel Open Source Technology Center
--
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/