linux-kernel - Re: [PATCH] kasan: use internal prototypes matching gcc-13 builtins

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: <e033ac24-0301-4c7f-8928-b940454c0a2b@app.fastmail.com>
Date:   Fri, 21 Apr 2023 16:40:33 +0200
From:   "Arnd Bergmann" <arnd@...db.de>
To:     "Marco Elver" <elver@...gle.com>, "Arnd Bergmann" <arnd@...nel.org>
Cc:     "Andrey Ryabinin" <ryabinin.a.a@...il.com>,
        "Andrew Morton" <akpm@...ux-foundation.org>,
        "Catalin Marinas" <catalin.marinas@....com>,
        "Will Deacon" <will@...nel.org>,
        "Alexander Potapenko" <glider@...gle.com>,
        "Andrey Konovalov" <andreyknvl@...il.com>,
        "Dmitry Vyukov" <dvyukov@...gle.com>,
        "Vincenzo Frascino" <vincenzo.frascino@....com>,
        "Mark Rutland" <mark.rutland@....com>,
        "Kees Cook" <keescook@...omium.org>,
        "Ard Biesheuvel" <ardb@...nel.org>,
        "Marc Zyngier" <maz@...nel.org>,
        "Matthew Wilcox" <willy@...radead.org>,
        "Vlastimil Babka" <vbabka@...e.cz>,
        "Peter Zijlstra" <peterz@...radead.org>,
        linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
        kasan-dev@...glegroups.com, linux-mm@...ck.org
Subject: Re: [PATCH] kasan: use internal prototypes matching gcc-13 builtins

On Fri, Apr 21, 2023, at 11:19, Marco Elver wrote:
>
> Does it work with Clang?

I tested successfully with clang-16, but did not try other versions so far.

> I don't mind either way, but the custom kasan_size_t change seems to
> just be needed to workaround the subtle inconsistency in type
> definition, but in reality there should never be a problem. I'd rather
> the KASAN code just uses normal kernel types and we just make the
> compiler be quiet about it.

Let me double-check, I think I may have made a mistake here, and
using the normal ssize_t (but not size_t) just works right. It looks
like I confused the size_t definition with something else, so this
hack may not be needed after all. I've changed it again now and will
give it another overnight test run on the randconfig setup.

> To do that, another option is -Wno-builtin-declaration-mismatch for
> mm/kasan/ which just shuts up the compiler, and allows us to keep the
> code as-is. Does it have any downsides?

I think the warning is useful in principle, at least it makes it
more likely to catch bugs if the prototypes ever change, and to
validate that things like __asan_allocas_unpoison() that I mentioned
are actually intentional.

      Arnd