linux-kernel - Re: [PATCH] x86 built-in command line (resend)

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] [day] [month] [year] [list]

Message-ID: <20060731205725.GL6908@waste.org>
Date:	Mon, 31 Jul 2006 15:57:25 -0500
From:	Matt Mackall <mpm@...enic.com>
To:	"H. Peter Anvin" <hpa@...or.com>
Cc:	linux-kernel <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...l.org>, ak@...e.de
Subject: Re: [PATCH] x86 built-in command line (resend)

On Mon, Jul 31, 2006 at 12:35:16PM -0700, H. Peter Anvin wrote:
> Matt Mackall wrote:
> >On Mon, Jul 31, 2006 at 12:07:02PM -0700, H. Peter Anvin wrote:
> >>Matt Mackall wrote:
> >>>I'm resending this as-is because the earlier thread petered out
> >>>without any strong arguments against this approach. x86_64 patch to
> >>>follow.
> >>"No strong arguments?"
> >>
> >>I still maintain that this patch has the wrong priority in case more 
> >>than one set of arguments are provided.
> >
> >But you still haven't answered how that lets you work around firmware
> >that passes parameters you don't like.
> >
> 
> That a fairly unique problem, and is most likely in a minority 
> application.  For that case a CONFIG option to ignore the 
> firmware-provided command line would make sense.  I do not believe it 
> should be the only option or even the default.

It's not the default. The default is all args come from the
bootloader.

At the risk of repeating myself, here are all possible features and
behaviors carefully enumerated again:

Possible features:
a) allow dealing with bootloaders that don't pass arguments
b) allow dealing with bootloaders that pass bogus arguments
c) allow dealing with bootloaders that run up against length limits
d) allow dealing with bootloaders where changing arguments dynamically
   is difficult
e) provide friendly defaults

Possible behaviors:
1) command line overrides built-in (won't work with b, works with the
rest)
2) built-in overrides command line (not so great for e, works with the
rest)
3) command line appends to built-in (generally broken as our command
parser can't arbitrarily override earlier arguments in most cases)
4) built-in appends to command line (same story)

Now I basically think behavior (e) is worthless. Embedded folks don't
care if the kernel's friendly and it's a solved problem for distros
too. Anyone else is building a kernel for themselves and don't need
defaults.

By comparison, the value of (b) is that you can control things you
otherwise can't. 

> It would be particularly good if this could be standardized across 
> architectures, which is another reason to do it right.

Yes. They should all clearly do (2).

-- 
Mathematics is the supreme nostalgia of our time.
-
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/