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:   Tue, 5 Jun 2018 22:35:43 +0259
From:   Thomas Backlund <tmb@...eia.org>
To:     Linus Torvalds <torvalds@...ux-foundation.org>,
        Ulf Magnusson <ulfalizer@...il.com>
CC:     Masahiro Yamada <yamada.masahiro@...ionext.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: building in 32bit chroot on x86_64 host broken


Den 2018-06-05 kl. 22:13, skrev Linus Torvalds:
> 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?
>
> Thomas, can you verify that a
>
>          git revert f467c5640c29ad258c3cd8186a776c82fc3b8057
>
> fixes the problem for you?
>
>                Linus

Yep, that fixes it so it works both  in the 32bit chroot and on the 
64bit host

--
Thomas