linux-kernel - Re: [PATCH] arm64/sve: fix genksyms generation

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:   Mon, 17 Jun 2019 17:10:32 +0200
From:   Arnd Bergmann <arnd@...db.de>
To:     Alex Bennée <alex.bennee@...aro.org>
Cc:     Will Deacon <will.deacon@....com>,
        Catalin Marinas <catalin.marinas@....com>,
        Dave Martin <Dave.Martin@....com>,
        Ard Biesheuvel <ard.biesheuvel@...aro.org>,
        Peter Maydell <peter.maydell@...aro.org>,
        Alan Hayward <alan.hayward@....com>,
        Julien Grall <julien.grall@....com>,
        Marc Zyngier <marc.zyngier@....com>,
        Mark Rutland <mark.rutland@....com>,
        Andrew Murray <andrew.murray@....com>,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] arm64/sve: fix genksyms generation

On Mon, Jun 17, 2019 at 4:59 PM Alex Bennée <alex.bennee@...aro.org> wrote:
> Arnd Bergmann <arnd@...db.de> writes:
> > On Mon, Jun 17, 2019 at 1:26 PM Will Deacon <will.deacon@....com> wrote:
> >> On Mon, Jun 17, 2019 at 12:42:11PM +0200, Arnd Bergmann wrote:
> >> I suspect I need to figure out what genksyms is doing, but I'm nervous
> >> about exposing this as an array type without understanding whether or
> >> not that has consequences for its operation.
> >
> > The entire point is genksyms is to ensure that types of exported symbols
> > are compatible. To do this, it has a limited parser for C source code that
> > understands the basic types (char, int, long, _Bool, etc) and how to
> > aggregate them into structs and function arguments. This process has
> > always been fragile, and it clearly breaks when it fails to understand a
> > particular type.
>
> Shouldn't the solution for this be to fix genksyms to be less fragile
> and more understanding? The code base doesn't seem to be full of these
> sorts of ifdef workarounds.

It is one of the things I tried before I got to the version I send.
Unfortunately
the genksyms codebase is a big complex and I quickly got lost in it.

You're welcome to volunteer fixing it though. My main problem was that
I couldn't even find out which types exactly are supported, as __uint128_t
is not even in the gcc documentation. "unsigned __int128" is a documented
type, but is also not in genksyms.

        Arnd