From: Slava Bacherikov <slava@bacher09.org>
To: Andrii Nakryiko <andrii.nakryiko@gmail.com>
Cc: Kees Cook <keescook@chromium.org>,
Andrii Nakryiko <andriin@fb.com>, bpf <bpf@vger.kernel.org>,
open list <linux-kernel@vger.kernel.org>,
Jann Horn <jannh@google.com>,
Alexei Starovoitov <alexei.starovoitov@gmail.com>,
Daniel Borkmann <daniel@iogearbox.net>,
Kernel Hardening <kernel-hardening@lists.openwall.com>,
Liu Yiding <liuyd.fnst@cn.fujitsu.com>,
KP Singh <kpsingh@google.com>
Subject: Re: [PATCH v3 bpf] kbuild: fix dependencies for DEBUG_INFO_BTF
Date: Wed, 1 Apr 2020 21:24:00 +0300 [thread overview]
Message-ID: <758ddac6-17ab-2e24-0199-ae0223517894@bacher09.org> (raw)
In-Reply-To: <CAEf4BzYx7hffHm5RV3QQQqvgAzy-41DRgFQDKh+4xcM9OL890A@mail.gmail.com>
01.04.2020 20:46, Andrii Nakryiko пишет:
> On Wed, Apr 1, 2020 at 7:38 AM Slava Bacherikov <slava@bacher09.org> wrote:
>>
>>
>>
>> 01.04.2020 17:20, Slava Bacherikov wrotes:
>>> Currently turning on DEBUG_INFO_SPLIT when DEBUG_INFO_BTF is also
>>> enabled will produce invalid btf file, since gen_btf function in
>>> link-vmlinux.sh script doesn't handle *.dwo files.
>>>
>>> Enabling DEBUG_INFO_REDUCED will also produce invalid btf file, and
>>> using GCC_PLUGIN_RANDSTRUCT with BTF makes no sense.
>>>
>>> Signed-off-by: Slava Bacherikov <slava@bacher09.org>
>>> Reported-by: Jann Horn <jannh@google.com>
>>> Reported-by: Liu Yiding <liuyd.fnst@cn.fujitsu.com>
>>> Acked-by: KP Singh <kpsingh@google.com>
>>> Acked-by: Andrii Nakryiko <andriin@fb.com>
>>> Fixes: e83b9f55448a ("kbuild: add ability to generate BTF type info for vmlinux")
>>> ---
>>> lib/Kconfig.debug | 4 +++-
>>> 1 file changed, 3 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
>>> index f61d834e02fe..b94227be2d62 100644
>>> --- a/lib/Kconfig.debug
>>> +++ b/lib/Kconfig.debug
>>> @@ -222,7 +222,9 @@ config DEBUG_INFO_DWARF4
>>>
>>> config DEBUG_INFO_BTF
>>> bool "Generate BTF typeinfo"
>>> - depends on DEBUG_INFO
>>> + depends on DEBUG_INFO || COMPILE_TEST
>> I had to add this, since DEBUG_INFO which depends on:
>>
>> DEBUG_KERNEL && !COMPILE_TEST
>>
>> would block DEBUG_INFO_BTF when COMPILE_TEST is turned on.
>>
>
> Sorry if I'm being dense here. But what's the point in enabling
> DEBUG_INFO_BTF if there is no *valid* DWARF info available for
> DWARF-to-BTF conversion?
As I mention in [0] there is no point in having `!GCC_PLUGIN_RANDSTRUCT
|| COMPILE_TEST` without `DEBUG_INFO || COMPILE_TEST`, since without it
COMPILE_TEST would block DEBUG_INFO_BTF and because of that
GCC_PLUGIN_RANDSTRUCT would be never blocked by BTF.
As far as I understood from [1] main point for all these these things
with COMPILE_TEST is to be able to check if kernel could be compiled
with all these options (e.g. check syntax, build scripts, etc).
I can rollback `DEBUG_INFO || COMPILE_TEST`, but in that case there is
no point in `GCC_PLUGIN_RANDSTRUCT || COMPILE_TEST` since COMPILE_TEST
in that case will not affect anything here, regardless from it's value.
[0]:
https://lore.kernel.org/bpf/202004010029.167BA4AA1F@keescook/T/#m2f493902d6aed09d30e5c4144a0164459386339d
[1]:
https://lore.kernel.org/bpf/202004010029.167BA4AA1F@keescook/T/#m8f25fab3476c9619249fee9ae692acb98c02cdc7
>
>
>> In that case allyesconfig will emit both:
>>
>> CONFIG_DEBUG_INFO_BTF=y
>> CONFIG_GCC_PLUGIN_RANDSTRUCT=y
>
> Which I thought is exactly what we wanted to avoid. Not sure what's
> the point of compiling kernel (even if it's the one that is not
> supposed to ever run) that apriori has broken BTF? If it was
> acceptable to not have DEBUG_INFO for COMPILE_TEST, why it's not
> acceptable to not have DEBUG_INFO_BTF in that situation as well?
>
>>
>>
>>
>>> + depends on !DEBUG_INFO_SPLIT && !DEBUG_INFO_REDUCED
>>> + depends on !GCC_PLUGIN_RANDSTRUCT || COMPILE_TEST
>>> help
>>> Generate deduplicated BTF type information from DWARF debug info.
>>> Turning this on expects presence of pahole tool, which will convert
>>>
next prev parent reply other threads:[~2020-04-01 18:24 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-31 21:55 [PATCH v2 bpf] kbuild: fix dependencies for DEBUG_INFO_BTF Slava Bacherikov
2020-03-31 22:40 ` KP Singh
2020-04-01 0:03 ` Andrii Nakryiko
2020-04-01 7:34 ` Kees Cook
2020-04-01 14:20 ` [PATCH v3 " Slava Bacherikov
2020-04-01 14:37 ` Slava Bacherikov
2020-04-01 17:46 ` Andrii Nakryiko
2020-04-01 18:24 ` Slava Bacherikov [this message]
2020-04-01 15:49 ` Kees Cook
2020-04-02 15:33 ` [PATCH v4 " Slava Bacherikov
2020-04-02 15:40 ` Slava Bacherikov
2020-04-02 19:31 ` Andrii Nakryiko
2020-04-02 20:34 ` Kees Cook
2020-04-02 20:38 ` Slava Bacherikov
2020-04-02 20:41 ` [PATCH v5 " Slava Bacherikov
2020-04-02 21:02 ` Andrii Nakryiko
2020-04-02 22:49 ` Daniel Borkmann
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=758ddac6-17ab-2e24-0199-ae0223517894@bacher09.org \
--to=slava@bacher09.org \
--cc=alexei.starovoitov@gmail.com \
--cc=andrii.nakryiko@gmail.com \
--cc=andriin@fb.com \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=jannh@google.com \
--cc=keescook@chromium.org \
--cc=kernel-hardening@lists.openwall.com \
--cc=kpsingh@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=liuyd.fnst@cn.fujitsu.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).