linux-kernel - BTF_KIND

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

Message-ID: <CAGvU0H=AAPt0wSTh1dyb-aTnG9zeUY6U2uBkmi6K9Bvpuc9YAA@mail.gmail.com>
Date:   Tue, 28 Jul 2020 21:56:52 +0100
From:   Giuliano Procida <gprocida@...gle.com>
To:     Yonghong Song <yhs@...com>
Cc:     linux-kernel@...r.kernel.org
Subject: BTF_KIND_FWD enums

Hi.

Re: https://github.com/torvalds/linux/commit/9d5f9f701b1891466fb3dbb1806ad97716f95cc3

Both GCC and LLVM support forward-declared (a.k.a. incomplete) enums
as a language extension -
https://gcc.gnu.org/onlinedocs/gcc/Incomplete-Enums.html.

(C++11 has a different notion of incomplete enum type - opaque enum
declaration - storage size is known but enumerators are not)

Forward-declared enums feature in various places in kernel code and
allow the usual things to be done (passing around pointers to such).
I'm curious as to if and how they are they are handled by BTF and
whether a further change to btf_type is needed:

1. Use BTF_KIND_FWD, with another spare bit to allow up to 4 kinds of
forward-declaration; or
2. use BTF_KIND_ENUM, kind_flag 0 and vlen 0 (as empty enums are
currently illegal C); or
3. use BTF_KIND_ENUM, kind_flag 1 and vlen 0.

If I had a working pahole -J, I'd test this myself. :-)

$ cat /tmp/en.c
enum H;
enum H * fun(enum H * x) { return x; }
$ clang -Wall -Wextra -ggdb -c /tmp/en.c
$ build/pahole -J /tmp/en.o
Segmentation fault
$ build/pahole -J /dev/null
btf_elf__new: cannot get elf header.
ctf__new: cannot get elf header.
Segmentation fault

My interest here is that I helped add support for incomplete enums to
libabigail which we're using to monitor kernel ABIs.

Regards,
Giuliano.

(resend due to email address typo)