linux-kernel - Re: [RFC v2 0/2] 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]

Date:	Thu, 21 Nov 2013 18:05:15 -0700
From:	jerry.hoemann@...com
To:	Matthew Garrett <mjg59@...f.ucam.org>
Cc:	rob@...dley.net, tglx@...utronix.de, mingo@...hat.com,
	hpa@...or.com, x86@...nel.org, matt.fleming@...el.com,
	yinghai@...nel.org, akpm@...ux-foundation.org, bp@...e.de,
	linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-efi@...r.kernel.org, penberg@...nel.org,
	mingo.kernel.org@...il.com, vgoyal@...hat.com
Subject: Re: [RFC v2 0/2] Early use of boot service memory

On Thu, Nov 21, 2013 at 11:38:31PM +0000, Matthew Garrett wrote:
> On Thu, Nov 21, 2013 at 04:31:04PM -0700, jerry.hoemann@...com wrote:
> 
> > I tried this back on 3.11 kernel and reserve_crashkernel after free of
> > boot services failed.  I will admit to not digging in too deeply as to
> > why it failed.
> 
> Hm. If the problem is fragmentation, then yeah, I can imagine this 
> causing problems. In that case we could take a two-pass approach - find 
> a gap that *will* be big enough, reserve everything that isn't currently 
> reserved, and then reserve the rest after ExitBootServices()?

Matthew,

Did you really mean EnterVirtualMode (not ExitBootServices?)

One of the difficulties i'm having is that distros and stable releases
want fixes upstream that they just back port.

ExitBootServices is called in different locations dependent upon
release.  The current use is to have linux do ExitBootServices, whereas
EBS used to be done in the boot loaders.  So, i'm concerned that 
such an approach might require legacy boot loader changes.  That would
be a difficult sell.

But,  splitting up what is done where may work.

While the crash kernel space is reserved early in boot,  i don't believe
it is written to until much later (kexec_load??)  So, i don't believe that
we'd loose any boot code/data that might be missed by firmware that tried
to access after ExitBootService.

In one of your earlier emails you mentioned the issue is that linux makes
regions NX.  That would cause problems if FW tried to execute a region
we just reserved.  Unfortunately, i'm not seeing where the kernel is
doing this for crash kernel memory.  Assuming it is making it NX, can
we defer that part?  Or if its not, do we have a problem w/ crash kernel
reservation at all?

Interesting questions, but as I don't have access to a system that has
the firmware defects encountered when efi_reserve_boot_services, it makes
it difficult to test that i don't break them.  Hence, the appealing nature
of quirks.  Don't have to worry about breaking other platforms as they
continue to operate same as before.

I can understand the desire some have to not introducing quirks.
They can be like potato chips.  You can't have just one.  :)  :)

-- 

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