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: <20131113235708.GC25344@anatevka.fc.hp.com>
Date:	Wed, 13 Nov 2013 16:57:08 -0700
From:	jerry.hoemann@...com
To:	"H. Peter Anvin" <hpa@...or.com>
Cc:	rob@...dley.net, tglx@...utronix.de, mingo@...hat.com,
	x86@...nel.org, matt.fleming@...el.com, yinghai@...nel.org,
	penberg@...nel.org, akpm@...ux-foundation.org,
	linux-doc@...r.kernel.org, linux-efi@...r.kernel.org,
	vgoyal@...hat.com, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/3] Early use of boot service memory

On Wed, Nov 13, 2013 at 02:49:42PM -0800, H. Peter Anvin wrote:
> On 11/13/2013 02:45 PM, jerry.hoemann@...com wrote:
> > 
> > The changes in 3.9 to allow crash kernel to be allocated high helps. 
> > But as you say, the default is still to allocate crash kernel low and
> > still susceptible to this problem.  So, a kdump expert can work around it.
> > But, not everyone is a kdump expert.
> > 
> > So, we can work to change the default, or encourage the distros
> > to always allocate high.  Or, we change the call to efi_reserve_boot_services
> > not apply to all platforms.
> > 
> > The problems for pre 3.9 based distros is worse as they don't have
> > ability to allocate crash kernel high.
> > 
> 
> But they won't have your new option, either,

I am working with distro partners on this issue.
I hope we can find a solution that all can live with.

> 				and that is still horribly
> manual and system-dependent.

I think i can go to a date based black list, that removes the manual
step.  System running firmware before certain date assumes we need
to do the work around.  If firmware is newer than that date, we don't
use the workaround.  Blacklist overrides and allows current behavior
for new firmware that is subsequently found to be broken and for
which we can't convenience the manufacturer to fix.

> 
> In other words, allocating the crashkernel high has ALL the advantages,
> plus a few more, and NONE of the disadvantages.
> 
> 	-hpa

Not exactly.

Firmware shouldn't be accessing these regions after exit boot services.
i like to find/fix firmware bugs.  efi_reserve_boot_services hides this
particular type of error.  Good or bad,  much of platform/firmware
validation is based upon booting/running OSes.

Also, there are kernel/tools rev locks in allocating crash kernel high.
Bigger, more coordination, etc...,

Don't get me wrong.  I think not restricting crash kernel allocation
to low memory is big improvement.  

I will still point out that as currently used, efi_reserve_boot_services
is wrong.  A work around for firmware bugs on one platform shouldn't be
breaking platforms that don't have that bug.  Its just much less likely
to cause problems with higher crash kernel allocation.

-- 

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