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] [day] [month] [year] [list]

Message-ID: <CAMj1kXED5EJRioKr2XMx5i6pbtcJJh29q-+jG547-=PFwHug3w@mail.gmail.com>
Date:   Sat, 11 Jul 2020 19:42:43 +0300
From:   Ard Biesheuvel <ardb@...nel.org>
To:     Arnd Bergmann <arnd@...db.de>
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, 11 Jul 2020 at 19:03, Arnd Bergmann <arnd@...db.de> wrote:
>
> 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.
>
>

Both changes sound like things we might simply upstream, no?
Randconfig is only intended for compile testing anyway, and making xip
depend on !COMPILE_TEST seems uncontroversial to me as well.