linux-kernel - Re: [RFC v2] bpf.2: Use standard types and attributes

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:   Tue, 04 May 2021 21:45:31 +0200
From:   Florian Weimer <fweimer@...hat.com>
To:     "Alejandro Colomar (man-pages)" <alx.manpages@...il.com>
Cc:     Zack Weinberg <zackw@...ix.com>,
        Greg KH <gregkh@...uxfoundation.org>,
        Daniel Borkmann <daniel@...earbox.net>,
        Alexei Starovoitov <alexei.starovoitov@...il.com>,
        "Michael Kerrisk (man-pages)" <mtk.manpages@...il.com>,
        linux-man <linux-man@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        glibc <libc-alpha@...rceware.org>, GCC <gcc-patches@....gnu.org>,
        bpf <bpf@...r.kernel.org>,
        Joseph Myers <joseph@...esourcery.com>,
        David Laight <David.Laight@...lab.com>
Subject: Re: [RFC v2] bpf.2: Use standard types and attributes

* Alejandro Colomar:

> The thing is, in all of those threads, the only reasons to avoid
> <stdint.h> types in the kernel (at least, the only explicitly
> mentioned ones) are (a bit simplified, but this is the general idea of
> those threads):
>
> * Possibly breaking something in such a big automated change.
> * Namespace collision with userspace (the C standard allows defining
>   uint32_t for nefarious purposes as long as you don't include
>  <stdint.h>.   POSIX prohibits that, though)
> * Uglier

__u64 can't be formatted with %llu on all architectures.  That's not
true for uint64_t, where you have to use %lu on some architectures to
avoid compiler warnings (and technically undefined behavior).  There are
preprocessor macros to get the expected format specifiers, but they are
clunky.  I don't know if the problem applies to uint32_t.  It does
happen with size_t and ptrdiff_t on 32-bit targets (both vary between
int and long).

Thanks,
Florian