linux-kernel - Re: [PATCH] Fix corruption of CONFIG_X86

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:	Tue, 31 May 2011 09:37:03 +0100
From:	David Woodhouse <dwmw2@...radead.org>
To:	Ted Ts'o <tytso@....edu>
Cc:	Ingo Molnar <mingo@...e.hu>, x86@...nel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] Fix corruption of CONFIG_X86_32 in 'make oldconfig'

On Mon, 2011-05-30 at 21:44 -0400, Ted Ts'o wrote:
> On some architectures, I suspect there will be a dozen or more CONFIG
> that have to be a certain way in order for the machine to boot.  Are
> you really going to want to put them all on the command line?

No. This is just a convenience for setting/clearing a few options
(although "make `cat my-config-overrides` oldconfig" would also work if
you have a bunch of them, I suppose.)

Remember, we're having this discussion because Ingo needs a command-line
method to override *just* CONFIG_64BIT. Nothing more. That's all that's
really holding us back from finally completing the i386/x86_64 -> x86
merge.

> I suppose the question is whether people are using randconfig for
> simple compile testing, or just for something that they actually try
> to boot, either on real hardware or on a KVM system.  I was under the
> impression Ingo and others actually tried to boot their randconfig
> kernels, correct? 

I *sincerely* hope that isn't the reason for this requirement. If they
*are* actually booting these kernels, then they'll need more than just
one setting to be hard-coded, as you correctly observe.

That would mean that they must already be using KCONFIG_ALLCONFIG, or an
'all.config' file which overrides the settings they need for their
storage hardware, for CGROUPS to match their userspace if they have
systemd, etc.

And that, in turn, would mean that all this whining about needing an
easier way to set CONFIG_64BIT is *pure* nonsense, because they could
have just added it to their existing list.

So no, allowing CONFIG_FOO= on the make command line was not intended as
a way to set options in bulk. We have *other* ways of doing that, which
do take them from a file.

-- 
dwmw2

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