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: <20131112175500.GA22363@anatevka.fc.hp.com>
Date:	Tue, 12 Nov 2013 10:55:01 -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>
Subject: Re: [PATCH 0/3] Early use of boot service memory

On Tue, Nov 12, 2013 at 12:37:29PM +0200, Pekka Enberg wrote:
> On Tue, Nov 12, 2013 at 4:15 AM, Jerry Hoemann <jerry.hoemann@...com> wrote:
> > Some platform have firmware that violates UEFI spec and access boot service
> > code or data segments after the system has called Exit Boot Services.
> > The call to efi_reserve_boot_services in setup_arch is a work around to
> > avoid using boot service memory until after the kernel has done
> > Set Virtual Map.
> >
> > However, this reservation fragments memory which can cause
> > large allocations early in boot (e.g. crash kernel) to fail.
> 
> What is the exact problem you're trying to solve here?

Pekka,

My primary motivation is fixing an issue that can causes kdump
to be disabled on a system.

Sequence of events:

1. The kernel calls efi_reserve_boot_services during setup_arch.

2. efi_reserve_boot_services reserves memory regions of type
   EFI_BOOT_SERVICES_CODE & EFI_BOOT_SERVICES_DATA.

3. setup_arch calls reserve_crashkernel().

4. start_kernel calls efi_free_boot_services which frees up the
   memory reserved by efi_reserve_boot_services().

The problem is that dependent upon the size of the crash kernel reservation,
the layout of the memory, and the location of the Boot Service Code and
Data segments,  reserve_crashkernel could fail where it would have
succeeded if the call to efi_reserve_boot_services hadn't been
made.

When reserve_crashkernel fails, kdump will be disabled.

The problem is made more apparent as large servers need large crash
kernel allocations.

The UEFI spec states that BS Code and Data segments are free
to be reused by an operating system after call to Exit Boot
Services.   Unfortunately,  some platforms apparently violate this 
portion of the spec and will use these segments as part of
the call to Set Virtual Map.  This can cause the system to crash
if Linux changed the content of the memory.

Hence,  the call to efi_reserve_boot_services was added as
a work around to platforms that violated this portion of the
UEFI spec.

Unfortunately,  the work around causes problems as described above.

For more background on efi_reserve_boot_services, please consult the thread:
https://lkml.org/lkml/2013/7/31/553

> How will the 
> problem be fixed for platforms that break the UEFI specification?
> 
>                         Pekka

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.

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/