linux-kernel - Re: arm-linux-gnueabi-ld: section .rodata VMA overlaps section .bss VMA

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:   Sat, 11 Jul 2020 18:03:17 +0200
From:   Arnd Bergmann <arnd@...db.de>
To:     Ard Biesheuvel <ardb@...nel.org>
Cc:     Russell King - ARM Linux admin <linux@...linux.org.uk>,
        kernel test robot <lkp@...el.com>,
        Kees Cook <keescook@...omium.org>, kbuild-all@...ts.01.org,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Nick Desaulniers <ndesaulniers@...gle.com>
Subject: Re: arm-linux-gnueabi-ld: section .rodata VMA overlaps section .bss VMA

On Sat, Jul 11, 2020 at 5:00 PM Ard Biesheuvel <ardb@...nel.org> wrote:
> On Sat, 11 Jul 2020 at 15:30, Russell King - ARM Linux admin
> <linux@...linux.org.uk> wrote:
> >
> > I doubt anyone is going to fix this; it's an XIP kernel, and it looks
> > like the .data and .rodata sections are correctly placed as per the
> > configuration, but for some reason the .text (and sections that follow)
> > are incorrectly placed in VMA space.  The configuration file says that
> > the kernel should start at 0x00080000, and there's no way the .text
> > VMA should be starting at 0x3f0801a0.
> >
>
> Note that only one of those lines has the >> prefix, and so this
> config was broken even before this patch got applied.
>
> > Unless one of the XIP using folk can debug this, I doubt there will be
> > any movement on it.  Especially as it's 5 months old...
> >
> > What do we do with bugs like this that people won't fix?  Remove XIP
> > support from the kernel?
> >
>
> I fail to see the point of randconfig testing for xip kernels tbh, and
> i don't think it is fair to disable xip altogether if the configs that
> those people care about still build as expected.
>
> But it would indeed be nice if we could at least get rid of these
> pointless build reports. Is there any way we can avoid xip from being
> selected by randconfig?

In my randconfig builds, I have a patch that makes CONFIG_XIP_KERNEL
and some other options depend on '!COMPILE_TEST', and I always enable
COMPILE_TEST for randconfig builds. I don't know whether that would
work for the kernel test robot as well.

      Arnd