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]

Message-ID: <20130913203812.GA312@anatevka.fc.hp.com>
Date:	Fri, 13 Sep 2013 14:38:12 -0600
From:	jerry.hoemann@...com
To:	Matt Fleming <matt@...sole-pimps.org>
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
Subject: Re: [edk2] Corrupted EFI region

On Thu, Aug 08, 2013 at 11:17:30AM +0100, Matt Fleming wrote:
> > Is it possible to have a switch to turn off the not required behavior
> > (hiding EFI implementation bugs) so that bad platforms could be
> > detected? This would be a good thing to try on platforms at the
> > upcoming UEFI Plugfest hosted by the Linux Foundation and the UEFI
> > Forum, so the bad behavior can be detected and the vendors can fix the
> > issue. 
> 
> We don't tend to provide switches for the kernel to turn off workarounds
> because users run the risk of inadvertently stopping their machines from
> booting correctly. Also, because the major distributions will always
> enable the workarounds, the kernel would need to be built manually to
> see any kind of informative error message.
> 

...

> 
> > PS Also maybe it would be possible to key this work around behavior on
> > the EFI/UEFI version. So for example no work-around after UEFI v2.3.1?
> 
> That would really depend on who has seen this bug and on which
> platforms. Is there a particular reason that mapping the boot services
> regions as-is would cause problems?
> 

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.

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.

thanks,

Jerry

-- 

----------------------------------------------------------------------------
Jerry Hoemann            Software Engineer              Hewlett-Packard

3404 E Harmony Rd. MS 57                        phone:  (970) 898-1022
Ft. Collins, CO 80528                           FAX:    (970) 898-XXXX
                                                email:  jerry.hoemann@...com
----------------------------------------------------------------------------

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