linux-kernel - Re: [PATCH] Raise the minimum GCC version to 5.2

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]

Message-ID: <CAHp75VdE9h9=CpzX094iJ52HR6Sz+f-qGfCt6YHfSPpG2Lb4-w@mail.gmail.com>
Date:   Tue, 4 May 2021 16:25:09 +0300
From:   Andy Shevchenko <andy.shevchenko@...il.com>
To:     Arnd Bergmann <arnd@...db.de>
Cc:     Matthew Wilcox <willy@...radead.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Segher Boessenkool <segher@...nel.crashing.org>,
        Joe Perches <joe@...ches.com>,
        Miguel Ojeda <miguel.ojeda.sandonis@...il.com>,
        Masahiro Yamada <masahiroy@...nel.org>,
        Albert Ou <aou@...s.berkeley.edu>,
        Linux Kbuild mailing list <linux-kbuild@...r.kernel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Jonathan Corbet <corbet@....net>,
        Linux Doc Mailing List <linux-doc@...r.kernel.org>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        Palmer Dabbelt <palmer@...belt.com>,
        Paul Walmsley <paul.walmsley@...ive.com>,
        Catalin Marinas <catalin.marinas@....com>,
        Miguel Ojeda <ojeda@...nel.org>,
        Paul Mackerras <paulus@...ba.org>,
        linux-riscv <linux-riscv@...ts.infradead.org>,
        linuxppc-dev <linuxppc-dev@...ts.ozlabs.org>,
        Will Deacon <will@...nel.org>,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH] Raise the minimum GCC version to 5.2

On Mon, May 3, 2021 at 12:29 PM Arnd Bergmann <arnd@...db.de> wrote:
>
> On Mon, May 3, 2021 at 9:35 AM Alexander Dahl <ada@...rsis.com> wrote:
> >
> > Desktops and servers are all nice, however I just want to make you
> > aware, there are embedded users forced to stick to older cross
> > toolchains for different reasons as well, e.g. in industrial
> > environment. :-)
> >
> > This is no show stopper for us, I just wanted to let you be aware.
>
> Can you be more specific about what scenarios you are thinking of,
> what the motivations are for using an old compiler with a new kernel
> on embedded systems, and what you think a realistic maximum
> time would be between compiler updates?
>
> One scenario that I've seen previously is where user space and
> kernel are built together as a source based distribution (OE, buildroot,
> openwrt, ...), and the compiler is picked to match the original sources
> of the user space because that is best tested, but the same compiler
> then gets used to build the kernel as well because that is the default
> in the build environment.
>
> There are two problems I see with this logic:
>
> - Running the latest kernel to avoid security problems is of course
>   a good idea, but if one runs that with ten year old user space that
>   is never updated, the system is likely to end up just as insecure.
>   Not all bugs are in the kernel.
>
> - The same logic that applies to ancient user space staying with
>   an ancient compiler (it's better tested in this combination) also
>   applies to the kernel: running the latest kernel on an old compiler
>   is something that few people test, and tends to run into more bugs
>   than using the compiler that other developers used to test that
>   kernel.

I understand that you are talking about embedded, but it you stuck
with a distro (esp. LTS one, like CentOS 7.x), you have gcc 4.8.5
there for everything, but they have got security updates. Seems if you
are with a distro you have to stick with its kernel with all pros and
cons of such an approach.


-- 
With Best Regards,
Andy Shevchenko