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: <20110530072300.GA9802@elte.hu>
Date:	Mon, 30 May 2011 09:23:00 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	David Woodhouse <dwmw2@...radead.org>
Cc:	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:

> I wasted a bunch of time today because I'd taken a .config from my 
> test machine and tried to build it, and the existing setting of 
> CONFIG_X86_32 got corrupted.
> 
> This patch fixes that. Last time I tried to fix this bug, I had to 
> contend with Ingo's objection that he didn't actually want 'make 
> randconfig' to give him a random config... [...]

You thoroughly misunderstood my prior regression report, the problem 
with your patch was that your patch actually *broke* existing 
filtered-randconfig behavior, for example trying to get a 64-bit 
randconfig:

  make ARCH=x86_64 randconfig

... will today produce a 64-bit randconfig while with your old change 
applied it produced a 32-bit randconfig 50% of the time.

That randconfig behavior is an entirely expected and intuitive: if 
the ARCH=x86_64 condition is added to the command line then kconfig 
should not ignore it - why should randconfig override the user's 
wishes? Furthermore this behavior worked fine before your first patch 
so not only did your first patch make kconfig behavior less 
intuitive, it also caused a regression.

Similarly, "make ARCH=i386 randconfig" will produce a 32-bit 
randconfig today, while with your old patch applied it produced a 
64-bit randconfig 50% of the time.

As i said it two years ago when you first submitted this patch:

 | I dont mind the change you are after, but randconfig should work as 
 | expected too: if ARCH=x86_64 is passed it should generate a 64-bit 
 | randconfig, not a 50% 32-bit one.

I still don't mind "make oldconfig" picking up the bitness of the 
.config instead of the host system's (it is the more intuitive and 
more correct behavior) - although note that me not minding it is not 
enough: we still have to be on the lookout for people and tools 
relying on that behavior.

So instead of complaining about my regression report i've updated the 
changelog as attached below - if you are fine with that then i'll 
commit and test it more widely.

Thanks,

	Ingo

-------------->
Subject: x86, kconfig: Pick up the .config arch version in 'make oldconfig'
From: David Woodhouse <dwmw2@...radead.org>
Date: Sun, 29 May 2011 23:14:28 +0100

I wasted a bunch of time today because I'd taken a .config from my 
test machine and tried to build it, and the existing setting of 
CONFIG_X86_32 got changed to the host system's bitness which was 
64-bit.

This patch fixes that. Last time I tried to fix this bug, I had 
introduced a regression that broke:

   make ARCH=x86_64 randconfig
   make ARCH=i386 randconfig

type of filtered-randconfig behavior which restricted randconfigs to 
64-bit and 32-bit configs, respectively.

This version fixes that so prior randconfig behavior is maintained.

Signed-off-by: David Woodhouse <David.Woodhouse@...el.com>
Link: http://lkml.kernel.org/r/1306707270.2029.377.camel@i7.infradead.org
Signed-off-by: Ingo Molnar <mingo@...e.hu>
---
 Makefile          |    3 ++-
 arch/x86/Kconfig  |    2 +-
 arch/x86/Makefile |    4 ++++
 3 files changed, 7 insertions(+), 2 deletions(-)

Index: linux/Makefile
===================================================================
--- linux.orig/Makefile
+++ linux/Makefile
@@ -165,7 +165,8 @@ export srctree objtree VPATH
 # then ARCH is assigned, getting whatever value it gets normally, and 
 # SUBARCH is subsequently ignored.
 
-SUBARCH := $(shell uname -m | sed -e s/i.86/i386/ -e s/sun4u/sparc64/ \
+SUBARCH := $(shell uname -m | sed -e s/i.86/x86/ -e s/x86_64/x86/ \
+				  -e s/sun4u/sparc64/ \
 				  -e s/arm.*/arm/ -e s/sa110/arm/ \
 				  -e s/s390x/s390/ -e s/parisc64/parisc/ \
 				  -e s/ppc.*/powerpc/ -e s/mips.*/mips/ \
Index: linux/arch/x86/Kconfig
===================================================================
--- linux.orig/arch/x86/Kconfig
+++ linux/arch/x86/Kconfig
@@ -1,7 +1,7 @@
 # Select 32 or 64 bit
 config 64BIT
 	bool "64-bit kernel" if ARCH = "x86"
-	default ARCH = "x86_64"
+	default ARCH != "i386"
 	---help---
 	  Say yes to build a 64-bit kernel - formerly known as x86_64
 	  Say no to build a 32-bit kernel - formerly known as i386
Index: linux/arch/x86/Makefile
===================================================================
--- linux.orig/arch/x86/Makefile
+++ linux/arch/x86/Makefile
@@ -2,7 +2,11 @@
 
 # select defconfig based on actual architecture
 ifeq ($(ARCH),x86)
+  ifeq ($(shell uname -m),x86_64)
+        KBUILD_DEFCONFIG := x86_64_defconfig
+  else
         KBUILD_DEFCONFIG := i386_defconfig
+  endif
 else
         KBUILD_DEFCONFIG := $(ARCH)_defconfig
 endif
--
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/