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: <1306852312.2029.596.camel@i7.infradead.org>
Date:	Tue, 31 May 2011 15:31:49 +0100
From:	David Woodhouse <dwmw2@...radead.org>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Ted Ts'o <tytso@....edu>, x86@...nel.org,
	linux-kernel@...r.kernel.org,
	Alexey Dobriyan <adobriyan@...il.com>,
	Randy Dunlap <rdunlap@...otime.net>
Subject: Re: [PATCH] Fix corruption of CONFIG_X86_32 in 'make oldconfig'

On Tue, 2011-05-31 at 15:56 +0200, Ingo Molnar wrote:
> The architecture *inside* the .config is not inherited automatically 
> but overriden by the host architecture, so due to this assymetry i 
> prefer to use explicit ARCH=xxx lines whenever i deal with configs.

Yes. That is why you *don't* need to run 'make ARCH=foo oldconfig' to
convert it to your native architecture; just 'make oldconfig' will work
fine.

I appreciate that you *like* to type it out anyway, and that's fine. Not
entirely sure how it's relevant to the rest of the discussion, except to
make you look a little sillier when you complain about the horrendous
amount of extra typing it is to use the new clean generic 'CONFIG_FOO='
interface instead of using the legacy ARCH values to set CONFIG_64BIT.

> > >     "I believe that this 'filtered randconfig' behaviour is now fairly much
> > >      the *only* use for the old 'ARCH=i386' and 'ARCH=x86_64'."
> > > 
> > > You are wrong again - it isnt, as me and others pointed it out.
> > 
> > Not *so* wrong that all those other use cases couldn't be addressed 
> > in the same, simple patch to allow CONFIG_FOO on the 'make' command 
> > line.
> 
> So "partially wrong" is not wrong? Indeed, if defined that way then i 
> agree that you must almost never be wrong ;-)

I said "this is fairly much the only remaining use", and some more use
cases were pointed out that were almost identical to the ones we'd
already discussed, and that were handled by the same patch.

Gosh, how wrong I was! You should shoot me now!

> Really, i have little interest in continuing the 'who was wrong' 
> angle of this discussion 

Very sensible. Hopefully we can agree that:

 - The only thing that ARCH=i386 and ARCH=x86_64 now do, since the
   merge into arch/x86, is override the setting of CONFIG_64BIT.

 - Until now, that override has also happened even when the user
   *didn't* pass any ARCH= on the command line. Instead of using the
   value of CONFIG_64BIT from the .config, it would automatically get
   changed to match the host!

 - This meant that people were forced to set ARCH= on the command line,
   just to make the build system honour the existing .config file.

 - The patch I submitted will make that override happen *only* when
   ARCH is explicitly specified as i386 or x86_64, which you use.
   It will *stop* it from happening when no ARCH= is specified. Yay!

 - The second patch I submitted will allow you to set *any* visible
   config symbol from the command line, which will be useful in many
   ways in addition to letting you set CONFIG_64BIT.

 - Now that you can set CONFIG_64BIT on the command line, the only
   remaining use of ARCH=i386 and ARCH=x86_64 is redundant.


Note that I've carefully avoided saying 'obsolete'. Only 'redundant',
which I'm sure you won't disagree with.

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