From mboxrd@z Thu Jan 1 00:00:00 1970 From: Quentin Monnet Subject: Re: [PATCH bpf-next 2/8] tools: bpftool: add probes for /proc/ eBPF parameters Date: Mon, 17 Dec 2018 10:44:45 +0000 Message-ID: References: <20181213121922.6652-1-quentin.monnet@netronome.com> <20181213121922.6652-3-quentin.monnet@netronome.com> <3fb543d9-0f76-20cf-e8ed-70d055e2503d@netronome.com> <443bd578-7e26-d2bd-2124-21b9f118c241@iogearbox.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Cc: netdev@vger.kernel.org, oss-drivers@netronome.com, Arnaldo Carvalho de Melo , Jesper Dangaard Brouer , Stanislav Fomichev To: Daniel Borkmann , Alexei Starovoitov Return-path: Received: from mail-wm1-f67.google.com ([209.85.128.67]:55895 "EHLO mail-wm1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726566AbeLQKos (ORCPT ); Mon, 17 Dec 2018 05:44:48 -0500 Received: by mail-wm1-f67.google.com with SMTP id y139so11765558wmc.5 for ; Mon, 17 Dec 2018 02:44:47 -0800 (PST) In-Reply-To: <443bd578-7e26-d2bd-2124-21b9f118c241@iogearbox.net> Content-Language: en-US Sender: netdev-owner@vger.kernel.org List-ID: 2018-12-16 01:14 UTC+0100 ~ Daniel Borkmann > On 12/15/2018 04:31 AM, Quentin Monnet wrote: >> 2018-12-15 00:40 UTC+0100 ~ Daniel Borkmann >>> On 12/13/2018 01:19 PM, Quentin Monnet wrote: >>>> Add a set of probes to dump the eBPF-related parameters available from >>>> /proc/: availability of bpf() syscall for unprivileged users, >>>> JIT compiler status and hardening status, kallsyms exports status. >>>> >>>> Sample output: >>>> >>>> # bpftool feature probe kernel >>>> Scanning system configuration... >>>> bpf() syscall for unprivileged users is enabled >>>> JIT compiler is disabled >>>> JIT compiler hardening is disabled >>>> JIT compiler kallsyms exports are disabled >>>> ... >>>> >>>> # bpftool --json --pretty feature probe kernel >>>> { >>>> "system_config": { >>>> "unprivileged_bpf_disabled": 0, >>>> "bpf_jit_enable": 0, >>>> "bpf_jit_harden": 0, >>>> "bpf_jit_kallsyms": 0 >>>> }, >>>> ... >>>> } >>>> >>>> # bpftool feature probe kernel macros prefix BPFTOOL_ >>>> #define UNPRIVILEGED_BPF_DISABLED UNPRIVILEGED_BPF_DISABLED_OFF >>>> #define UNPRIVILEGED_BPF_DISABLED_OFF 0 >>>> #define UNPRIVILEGED_BPF_DISABLED_ON 1 >>>> #define UNPRIVILEGED_BPF_DISABLED_UNKNOWN -1 >>>> #define JIT_COMPILER_ENABLE JIT_COMPILER_ENABLE_OFF >>>> #define JIT_COMPILER_ENABLE_OFF 0 >>>> #define JIT_COMPILER_ENABLE_ON 1 >>>> #define JIT_COMPILER_ENABLE_ON_WITH_DEBUG 2 >>>> #define JIT_COMPILER_ENABLE_UNKNOWN -1 >>>> #define JIT_COMPILER_HARDEN JIT_COMPILER_HARDEN_OFF >>>> #define JIT_COMPILER_HARDEN_OFF 0 >>>> #define JIT_COMPILER_HARDEN_FOR_UNPRIVILEGED 1 >>>> #define JIT_COMPILER_HARDEN_FOR_ALL_USERS 2 >>>> #define JIT_COMPILER_HARDEN_UNKNOWN -1 >>>> #define JIT_COMPILER_KALLSYMS JIT_COMPILER_KALLSYMS_OFF >>>> #define JIT_COMPILER_KALLSYMS_OFF 0 >>>> #define JIT_COMPILER_KALLSYMS_FOR_ROOT 1 >>>> #define JIT_COMPILER_KALLSYMS_UNKNOWN -1 >>>> ... >>> >>> Hm, given these knobs may change at any point in time, what would >>> be a use case in an application for these if they cannot be relied >>> upon? (At least the jit_enable and jit_harden are transparent to >>> the user.) >> >> Granted, for those parameters it's a snapshot of the system at the time >> the probes are run. It can be useful, I suppose, if a server is not >> expected to change them often... And the plain output might be useful to >> a sysadmin who wants to have a quick look at BPF-related parameters, maybe? > > Hmm, but wouldn't the main purpose of this header file be to include it > into a BPF program to selectively enable / disable features (e.g. LPM > map vs hashtab when kernel does not support LPM type as one example)? > What would a use-case be for the above defines used inside such BPF prog? > (Similarly for the kernel config defines in the other patch, how would > a BPF prog use them?) > > I think perhaps the 'issue' is that the C-style header generation and json > dump are dumping the /exact/ same information. Is this a requirement? > Wouldn't it be better to evolve the two /independently/? > > E.g. the system_config bits from the json dump and BPF-related kernel > config, perhaps also a listing of available maps, progs with supported > helpers for a prog would be useful for the json dump for an admin or > orchestration daemon to adapt to the underlying kernel where it could > just parse the json and doesn't have to do the queries by itself. > > But for the header generation, I would only place defines in there that > are strictly relevant for the BPF program author. Available maps, progs > and helpers is a good start there, later we could also put others in there > such as [0] and similar specifics or quirks to verifier behavior that > would be relevant in terms of work-arounds for supporting different kernel > versions; but on a case by case basis. There things might potentially be > less interesting for a json dump (though the json dump could overall be > a superset of the info from the header file). > > [0] https://github.com/cilium/cilium/blob/master/bpf/probes/raw_mark_map_val.t > For the use case about kernel config options, I was thinking about Cilium which collects some of them as well [0], but maybe it's not worth having it in the C-style header for now. For procfs parameters, maybe it's not so relevant indeed to have them at all in this output. So you have a point, I suppose. I do not have any hard requirement about having the #define and the JSON similar; I argued with Stanislav that I didn't want to introduce small losses of information between the two, but if we consider them entirely different from the start it is not the same thing... So maybe I should just stick to the basics for the #define output, as you suggest. I've seen the other probes used by Cilium, but I intentionally left the most specific one aside for now, there's enough to do with the current probes :). But yeah, it would make sense to have them added in the future. And for the record, I like the idea of keeping JSON a superset of the available information indeed. I'll go with just prog/map types and helpers for the #define in my next version. This should also settle the discussion on the format of the macros used in this first version for the procfs parameters. Thanks! Quentin [0] https://github.com/cilium/cilium/blob/master/bpf/run_probes.sh#L37