linux-kernel - Re: building in 32bit chroot on 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]

Date:   Wed, 6 Jun 2018 10:37:49 +0900
From:   Masahiro Yamada <yamada.masahiro@...ionext.com>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     tmb@...eia.org, Ulf Magnusson <ulfalizer@...il.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: building in 32bit chroot on x86_64 host broken

Hi Linus, Thomas,


2018-06-06 4:13 GMT+09:00 Linus Torvalds <torvalds@...ux-foundation.org>:
> On Tue, Jun 5, 2018 at 11:50 AM Thomas Backlund <tmb@...eia.org> wrote:
>> >
>> > but why do you care?
>>
>> Because without it running the build in the 32bit chroot will get the
>> initial reported issue:
>
> Ahh. I can re-create that now.
>
> Yes, doing
>
>       make ARCH=i386 allnoconfig
>
> followed by
>
>       make oldconfig
>
> is broken. And doing a trivial "git bisect run" to pinpoint where
> CONFIG_64BIT goes away gives us
>
> f467c5640c29ad258c3cd8186a776c82fc3b8057 is the first bad commit
>
> which does that
>
>   "kconfig: only write '# CONFIG_FOO is not set' for visible symbols"
>
> and it turns out that CONFIG_64BIT is not a visible symbol on x86-32,
> because that question is disabled when ARCH != "x86".
>
>         bool "64-bit kernel" if ARCH = "x86"
>
> And the problem with that, is that *next* time around this config file
> is used, because we don't have that
>
>   # CONFIG_64BIT is not set
>
> line, we don't turn it into
>
>   CONFIG_64BIT=n
>
> and then the "depends on" in X86_64
>
>   config X86_64
>           def_bool y
>           depends on 64BIT
>
> no longer hides it.
>
> Hmm. Ulf, Masahiro, comments?
>
> Should we just revert that commit?


Hmm.

Was the v4.16 behavior intentional,
or just something people found to work?


IMHO, the current behavior in v4.17 is expected
from the Kconfig point of view.


"make ARCH=i386 allnoconfig" hides the prompt
of 64BIT.

Then, "make oldconfig" makes the prompt newly visible,
so it is asking for user input.



However, the previous behavior is desired,
I think we can change the course.




If a symbol is visible (i.e. there is no unmet direct dependency),
'# CONFIG_... is not set' should be written out to the .config
even if its prompt is invisible.


For example,


config FOO
       bool


should write out "# CONFIG_FOO is not set"


I think this will fix the reported problem,
and Kconfig can still keep the grammatical consistency.


Ulf, what do you think?








> Thomas, can you verify that a
>
>         git revert f467c5640c29ad258c3cd8186a776c82fc3b8057
>
> fixes the problem for you?
>
>               Linus



-- 
Best Regards
Masahiro Yamada