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]

Message-ID: <20110530113447.GB22324@elte.hu>
Date:	Mon, 30 May 2011 13:34:47 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	David Woodhouse <dwmw2@...radead.org>
Cc:	Theodore Tso <tytso@....EDU>, x86@...nel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] Fix corruption of CONFIG_X86_32 in 'make oldconfig'


* David Woodhouse <dwmw2@...radead.org> wrote:

> On Mon, 2011-05-30 at 12:58 +0200, Ingo Molnar wrote:
> > 
> > * Theodore Tso <tytso@....EDU> wrote:
> > 
> > > I'd think that "make ARCH=x86_64 oldconfig"
> > > 
> > > ... where the old configuration contained CONFIG_X86_32
> > > should trigger a warning, if not an outright error that 
> > > stops the build....
> > 
> > That would be a rather sad regression for me: i use that command 
> > regularly to transform .configs that came in bugreports into a config 
> > suitable for a testbox that has a different bitness userspace 
> > installed. 
> 
> And if it has a different SCSI or ATA controller? Then you need
> something like:
> 
> 	'make CONFIG_SATA_MV=y oldconfig'
> 
> to make your config actually useful.

When it wont boot straight away (often it does) i use a 
Kconfig-needed set of minimal set of configs that enables the minimal 
hardware environment.

But bitness is not really a 'hardware environment' thing - it's a CPU 
mode thing that i want to match to 32-bit or 64-bit user-space, 
depending on which one i want to boot.

So bitness *is* special, even if we ignored all the well-established 
workflows where people became to rely on (and appreciate) what 
ARCH=i386 and ARCH=x86_64 specifiers give us today and which ARCH=x86 
does not replace in an equivalent fashion.

Thanks,

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