linux-kernel - Re: [PATCH 0/3] Early use of boot service memory

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: <20131112215200.GB22363@anatevka.fc.hp.com>
Date:	Tue, 12 Nov 2013 14:52:00 -0700
From:	jerry.hoemann@...com
To:	Pekka Enberg <penberg@...nel.org>
Cc:	Rob Landley <rob@...dley.net>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>,
	"H. Peter Anvin" <hpa@...or.com>, x86 maintainers <x86@...nel.org>,
	Matt Fleming <matt.fleming@...el.com>,
	Yinghai Lu <yinghai@...nel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	"list@...ederm.org:DOCUMENTATION <linux-doc@...r.kernel.org>,
	list@...ederm.org:MEMORY MANAGEMENT <linux-mm@...ck.org>," 
	<linux-doc@...r.kernel.org>, linux-efi@...r.kernel.org,
	Vivek Goyal <vgoyal@...hat.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Matthew Garrett <mjg59@...f.ucam.org>
Subject: Re: [PATCH 0/3] Early use of boot service memory

On Tue, Nov 12, 2013 at 08:48:51PM +0200, Pekka Enberg wrote:
> Hi Jerry,
> 
> On Tue, Nov 12, 2013 at 7:55 PM,  <jerry.hoemann@...com> wrote:
> > My change does not address platforms that have misbehaving firmware.
> > It just allows platforms that don't have this issue to avoid issues
> > that the call to efi_reserve_boot_services presents.
> 
> The problem I have with your patch is that it (1) relies on users to
> pass a kernel option and (2) leaves machines with "faulty firmware" out
> in the cold.  So I'm wondering if we can fix reserve_crashkernel() to
> deal with reality that there indeed are broken firmware out there?
> 
> If someone is able to come up with a convincing argument why crashkernel
> cannot be fixed on such machines, we'd need to start whitelisting known
> good firmwares, no?
> 
>                            Pekka

Hi Pekka,

I'm cc'ing Matthew Garrett who has the background in the original
problem that efi_reserve_boot_services was used to work around.

Matthew, sorry for not CC'ing you initially.

Also, a more specific message from Matthew from the earlier thread:

	https://lkml.org/lkml/2013/8/7/750

I was anticipating this extended argument to be used by distros
that support servers.  While technically still a problem on smaller
systems, the crash kernel size requirement for larger systems makes
the issue much more apparent.  Also, having this in distros could help
enforce proper behaving platforms going forward as companies will
want to get their platforms certified.

I don't believe the proposed change "hurts" the platforms that
efi_reserve_boot_services was added to protect.  They'll function
as they do now,  they just shouldn't add the new argument.

I've conducted a couple test previously: https://lkml.org/lkml/2013/9/18/457.

Moving reserve crash_kernel after efi_free_boot_services failed.
While moving it before efi_reserve_boot_services seems to work,
this would also move it before trim_platform_memory_ranges, which I was
concerned would break other platforms.

If we were to go to a list method,  i'd rather we tried to define
the blacklist of platforms that require the efi_reserve_boot_services
workaround.

In testing new platforms, its much easier to assume that the platform works.
Only if it doesn't work, and the platform hardware/firmware defects
can't be fixed, then we can black list it.

The issue on how to work around EFI bugs before has been discussed,
but I don't recall seeing a resolution.  If I missed this, point
me in right direction.  :)

thanks

Jerry

-- 

----------------------------------------------------------------------------
Jerry Hoemann            Software Engineer              Hewlett-Packard/MODL

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/