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]

Date:	Thu, 14 Nov 2013 17:50:49 -0700
From:	jerry.hoemann@...com
To:	Pekka Enberg <penberg@...nel.org>
Cc:	"H. Peter Anvin" <hpa@...or.com>, Rob Landley <rob@...dley.net>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.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 Thu, Nov 14, 2013 at 08:44:04PM +0200, Pekka Enberg wrote:
> On Thu, Nov 14, 2013 at 8:04 PM,  <jerry.hoemann@...com> wrote:
> > Making this issue a quirk will be a lot more practical.  Its a small, focused
> > change whose implications are limited and more easily understood.
> 
> There's nothing practical with requiring users to pass a kernel option
> to make kdump work.  It's a workaround, sure, but it's not a proper
> fix.

One already has to specify command line arguments to enable kdump.
See "crashkernel=" in Documentation/kernel-parameters.txt.

As i said in an earlier mail we are working w/ distros.  distros
can and do specify lots of interesting command line arguments for
their systems.  Distros have tools for configuring kdump.
User must already use these tools or manually edit multiple config files,
to get kdump to work.  I would work with distros to help integrate this
change into their tools.

As i said in earlier mail, i am willing to change implementation
to some type of black/white listing.

> 
> And once you add whitelisting to make it practical, implications are
> no longer limited nor easily understood nor actually testable unless
> you happen to have access every single firmware out there.

Perhaps we have a different understanding of black/white listings.

Here is what i mean:

the use of efi_reserve_boot_services is a work around for system
with fw bugs.

Black list:
1. In general, assume systems don't need the work around.
2. The black list are those specific system on which the work around
   is applied.

White list:
1. In general, assume systems require the work around.
2. The white list are those specific system in which the work around
   is not applied.

In the white list case, the list of platforms would be the ones
that i specifically test and verify don't need the work around.
the only difference is whether BootService Code/Data is reserved/freed
early.

all other platforms remain the same.

> 
> Yes, we have plenty of quirks in the x86 boot code but that doesn't
> mean it's a good idea to add more of the unless we absolutely must.

given that life is optional, how can one argue any piece of software be
an absolute must?  :)  :)

Jerry

> 
>                                 Pekka

-- 

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