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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <alpine.LNX.2.00.1212262323410.23814@swampdragon.chaosbits.net>
Date:	Wed, 26 Dec 2012 23:30:26 +0100 (CET)
From:	Jesper Juhl <jj@...osbits.net>
To:	David Rientjes <rientjes@...gle.com>
cc:	David Woodhouse <dwmw2@...radead.org>,
	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, 26 Dec 2012, David Rientjes wrote:

> On Wed, 26 Dec 2012, David Woodhouse wrote:
> 
> > > I'm sure it's a 32-bit issue, nothing has changed recently in auto-latest 
> > > related to these subsystems and I'm sure it's just because my randconfig 
> > > builds were exposed to this combination solely because of this patch.
> > 
> > Hm, that's an unexpected benefit of this patch. I didn't think it would
> > noticeably improve 'make randconfig' coverage of configs without
> > CONFIG_64BIT, because I thought enough people were doing such tests
> > already. But evidently I was wrong.
> > 
> 
> I do quite a bit of automated config and boot tests to try out 
> combinations that others may not have tested when developing their code; 
> staging branches such as in tip are interesting to try because they 
> haven't yet reached Linus and it's helpful to catch breakages before it 
> reaches mainline.
> 
> > We introduced 'make randconfig' as a tool to generate meaningless
> > configs just to test various permutations — to ensure that we got our
> > dependencies right both in Kconfig and the code itself. It was
> > artificially limiting its test coverage and thus we were failing to
> > discover real bugs. Now I've fixed that problem, and 'make randconfig'
> > is actually random and is thus doing its job even better than before.
> > Yay!
> > 
> 
> 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.  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.
> 
...

Why would you assume a bootable kernel from 'randconfig'? I don't and 
never have. If we stick to X86, then you may get a kernel config without 
x387/emulator support - try to boot boot that on a 486sx. You may also get 
a config that does not contain the filesystem(s) you use, or without the 
driver for your main HD. You may also be out of luck with graphics 
drivers or support for your mouse/keyboard combo. etc etc.

In my view, randconfig was never about building bootable kernels, but all 
about building possible kernel config combinations - that may or may not 
boot on any given system.  The point was only to test that some 
combination of options did in fact build (if it also boots then all the 
better, but that was never part of the goal; as I saw it).

I may be wrong, but that was/is my expectations for 'randconfig'.

-- 
Jesper Juhl <jj@...osbits.net>       http://www.chaosbits.net/
Don't top-post http://www.catb.org/jargon/html/T/top-post.html
Plain text mails only, please.