bpf.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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
>>>

  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).