linux-kernel - Re: [tip:x86/build] x86: Default to ARCH= x86 to avoid overriding CONFIG

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1356560399.7010.45.camel@shinybook.infradead.org>
Date:	Wed, 26 Dec 2012 22:19:59 +0000
From:	David Woodhouse <dwmw2@...radead.org>
To:	David Rientjes <rientjes@...gle.com>
Cc:	Ingo Molnar <mingo@...nel.org>, "H. Peter Anvin" <hpa@...or.com>,
	tglx@...utronix.de, "H. Peter Anvin" <hpa@...ux.intel.com>,
	linux-kernel@...r.kernel.org, linux-tip-commits@...r.kernel.org
Subject: Re: [tip:x86/build] x86: Default to ARCH= x86 to avoid overriding
 CONFIG_64BIT

On Wed, 2012-12-26 at 14:00 -0800, David Rientjes wrote:
> Umm, you're saying that is legitimate for "make randconfig" done on a 
> 32-bit machine to generate 64-bit configurations?  The resulting kernel 
> cannot be booted. 

It has never been expected that a 'randconfig' kernel would actually
boot. And yes, it's absolutely legitimate for 'make randconfig' on a
32-bit machine to generate 64-bit configurations. And for 'make
randconfig' on a machine without PAE to generate a kernel which uses
(and thus requires) PAE. And for 'make randconfig' on a machine without
3DNow to generate a kernel that uses (and thus requires) 3DNow.

That's exactly what you get on every other architecture, isn't it?
Random means random. It's only x86 that never quite finished the merge
of arch/i386 and arch/x86_64 into one, and was inconsistent.

>  In the past, "make randconfig" would always generate a kernel that
> _should_ boot on that machine unless there was an underlying 
> bug that should be fixed.

No, that was not the case. I've given some examples above — and good
luck mounting your root file system if you have neither the block device
nor the corresponding file system support. Not to mention CGROUPS
support or whatever else your userland requires in order to boot.

If you want it bootable, there *are* ways for you to override just
enough of the config options to ensure that — as I've repeatedly said.
But doing *just* CONFIG_64BIT is far from sufficient.

> > > > Please could you provide the .config file?
> > 
> > > Attached.
> > 
> > Didn't seem to be.
> > 
> 
> Now it is, sorry.

Thanks. I'll look into this. I presume it was *always* failing, but
nobody happened to come across it because our test coverage of x86
configs without CONFIG_64BIT wasn't particularly good?

> > I just don't buy this "OMG you made randconfig actually random" crap.
> > It's a stupid thing to complain about. Making some effort to pick
> > i386_defconfig or x86_64_defconfig according to the build host, we can
> > tolerate. But randconfig is *supposed* to be random. Get over it.
> > 
> 
> I'm stupid for saying that you've changed the behavior of "make 
> randconfig" with no ARCH= workaround so that it may result in an 
> unbootable kernel on i386? 

Nothing changed significantly there. You could *always* get an
unbootable kernel that way. The *odds* may have changed, but that's all.

The mechanism for you to *ensure* that you get a bootable result, as I
keep reminding you, still works fine.

-- 
dwmw2

Download attachment "smime.p7s" of type "application/x-pkcs7-signature" (6171 bytes)