[Buildroot] pkg-kconfig woes with linux 5.7

Tue May 12 09:55:50 UTC 2020

Hello All,

The soon-to-be-released linux 5.7 has changed the way it detects the
ability of gcc to use plugins, when it dropped support for gcc 4.7 or
older [0].

To detect the ability to use gcc plugins, the kernel has to check whther
the host gcc is capable enough to build them.

When we call one of the configurator for the linux kernel, we explicitly
pass a value of HOSTCC=$(HOSTCC_NOCCACHE), because there might be a
discrepancy between the ncurses headers and libraries as found by the
linux kconfig build [1] [2].

But then, when we build the kernel, we pass another value to use [3]
HOSTCC="$(HOSTCC) $(HOST_CFLAGS) $(HOST_LDFLAGS)" which boils down to
roughly: gcc -I.../host/include -L.../host/lib -Wl,-rpath,.../host/lib
This is needed so that at build time, the kernel can build host tools
that link with our openssl et al.

So, the two HOSTCC we pass to the kernel may have different behaviours.
For example, on my machine, gmp.h is missing in the ystem, but it is
available in $(O)/host/ when using an internal toolchain (and under a
few other conditions).

In that case, when configuring the kernel, it decides that the host
compiler can't build plugins, so the dependencies of CONFIG_GCC_PLUGINS
are not met, and that option is not present in the linux' .config file
(neither as "=y" nor as "is not set"). But then, when we build the
kernel, the host compiler suddenly becomes capable of building the
plugins, and the internal syncconfig run by the kernel will notice that
the dependencies of CONFIG_GCC_PLUGINS are now met, and that the user
shall decide on its value. And this blocks a build on an interactive
console (abbreviated):

    * Restart config...
    * GCC plugins
    GCC plugins (GCC_PLUGINS) [Y/n/?] (NEW) _

But most problematic is the behaviour when run in a shell that is not
interactiove (e.g. a CI job or such) (abbreviated):

    * Restart config...
    * GCC plugins
    GCC plugins (GCC_PLUGINS) [Y/n/?] (NEW)
    Error in reading or end of file.
      Generate some entropy during boot and runtime (GCC_PLUGIN_LATENT_ENTROPY) [N/y/?] (NEW)
    Error in reading or end of file.
      Randomize layout of sensitive kernel structures (GCC_PLUGIN_RANDSTRUCT) [N/y/?] (NEW)
    Error in reading or end of file.
    * Memory initialization
    Initialize kernel stack variables at function entry
    > 1. no automatic initialization (weakest) (INIT_STACK_NONE)
      2. zero-init structs marked for userspace (weak) (GCC_PLUGIN_STRUCTLEAK_USER) (NEW)
      3. zero-init structs passed by reference (strong) (GCC_PLUGIN_STRUCTLEAK_BYREF) (NEW)
      4. zero-init anything passed by reference (very strong) (GCC_PLUGIN_STRUCTLEAK_BYREF_ALL) (NEW)
    choice[1-4?]:
    Error in reading or end of file.
    Poison kernel stack before returning from syscalls (GCC_PLUGIN_STACKLEAK) [N/y/?] (NEW)
    Error in reading or end of file.
    Enable heap memory zeroing on allocation by default (INIT_ON_ALLOC_DEFAULT_ON) [N/y/?] n
    Enable heap memory zeroing on free by default (INIT_ON_FREE_DEFAULT_ON) [N/y/?] n

In either case, the behaviour is incorrect, and has already been
reported both on list [4] and on IRC [5].

Fixing this issue is by far not straightforward.

The most obvious and simple solution would be to unconditionally disable
gcc plugins alltogether, with:

    define LINUX_KCONFIG_FIXUP_CMDS
        [...]
        $(call KCONFIG_DISABLE_OPT,CONFIG_GCC_PLUGINS)
        [...]
    endif

But that can't work either, because after applying the fixups, we call
olddefconfig (or the likes) with the incapable HOSTCC, so the disabled
option would be removed anyway, and we'd be back to square one.

Another solution would be to hack the disabling call just before
building the kernel (in _addition_ to the above):

    define LINUX_BUILD_CMDS
        $(call KCONFIG_DISABLE_OPT,CONFIG_GCC_PLUGINS)
        [...]
    endef

Even though that would work, this is not nice, as this indeed prevents
users from using gcc plugins, even though their HOSTCC is already
capable without using anything from $(O)/host/

This could be an appropriate makeshift, though, because we so far did
not allow using gcc plugins with linux 5.6 or older. So that would not
be a regression or a new limitation.

The best solution would be if we were able to build the configurators
separately from invoquing them. The linux kernel has a few targets to
that effect: build_menuconfig et al., but it lacks build_config. Other
packages (busybox, uboot, barebox...) will most probably be lacking
those, though, so we'd have to be conditional (like we do to check
whether to call olddefconfig or run yes "" |oldconfig). And still, that
would require a way for the pkg-kconfig infra to accept different
options, to build the configurators and run them (the existing
FOO_KCONFIG_OPTS is used by both.

Any hint? Any suggestion?

[0] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=77342a02ff6e14645916d85c8550dd1011c4f7d7
[1] https://git.buildroot.org/buildroot/tree/linux/linux.mk#n287
[2] https://git.buildroot.org/buildroot/commit/linux/linux.mk?id=6d3d09e23213e88c14f2ddc883700499315a41bc
[3] https://git.buildroot.org/buildroot/tree/linux/linux.mk#n132
[4] http://lists.busybox.net/pipermail/buildroot/2020-April/thread.html#281581
[5] https://pastebin.com/8rNDjiNv

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 561 099 427 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'