Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp1250978pxu; Fri, 27 Nov 2020 03:22:17 -0800 (PST) X-Google-Smtp-Source: ABdhPJx/GKFLuX/WZnjwdXkhpMxsbt5pvyhyUnIYy+zejbalq8U7XAPxXCgVWDpRNeiobha35CKX X-Received: by 2002:a50:d886:: with SMTP id p6mr7468911edj.366.1606476137572; Fri, 27 Nov 2020 03:22:17 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1606476137; cv=none; d=google.com; s=arc-20160816; b=s6pkGqCSkjMEBPnVrgBBRY0uAIsBCS98bhEoKPNspUFZUBE7nFg1D85DySFZHSNVDR eoFCOK0n1B6rd/PCrtYr9ueEGavmt0GGiPJpFStsG+vct9aKQBwqG1aJGzTTfbiljjDM DQ3qeegP2u65HnZrxU+A2u9LrebU5cIBst+jGRxGz0PGsfQrVwaPOSeMqnwqMyU4OfFU NXcB0zdptECgtPMmayvVwShLbJeyTlPBZWLN/ixo19ZA1Wk8ohDnFStoxndAFJkfyzT+ Qpm/yjCZILjNPPz+/lU1Nyrd0fESd5j58cRPpFuk6KJMT/qauqV2QPWPXjvnW8voOof+ trXw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=Gx/sfWK7RQOwUhoWCcsjhmPBNWJ/nVv9as+ArKz2/0k=; b=aeuPQ9ArNGFyZj1xl3ayIrKW0jlAamIFFQeUTs5jp8sF50WzpA7b75BDEZ44o6OEDH EymOC5xmkAEP8MkdXIvj3zY0sQasCne81uNjju8tMFG73xigXWYP96GrZsn5fdi7Grjp fnYQt6cQO0Q5WHm/BISP9FcAMUaFFErJ/dzuBg52w3RYh6RJDoYan++TEdcoP/Jw7i/Q vUXFFJTG0DJ1oPMiZ2J4S4eIsycUccj5QksevqFm+y+OeZF/iXcXBVXO8yrVEx3a87E9 gd5zwtpQAeOjASdNpP5XmSI1sDr2KEVCfTC3JntGeHEHx5Hn7y3kUCnJrsRMN6QQ+wFZ uvKA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=LpxDn9xb; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id r9si4806094ejo.134.2020.11.27.03.21.55; Fri, 27 Nov 2020 03:22:17 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=LpxDn9xb; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729164AbgK0LUO (ORCPT + 99 others); Fri, 27 Nov 2020 06:20:14 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60458 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728451AbgK0LUN (ORCPT ); Fri, 27 Nov 2020 06:20:13 -0500 Received: from mail-lj1-x243.google.com (mail-lj1-x243.google.com [IPv6:2a00:1450:4864:20::243]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BC5D0C0613D4 for ; Fri, 27 Nov 2020 03:20:12 -0800 (PST) Received: by mail-lj1-x243.google.com with SMTP id z1so5542474ljn.4 for ; Fri, 27 Nov 2020 03:20:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Gx/sfWK7RQOwUhoWCcsjhmPBNWJ/nVv9as+ArKz2/0k=; b=LpxDn9xb1o6vIwYbn0D7fOmklaeebC5h3J5u9lUnRCxHaOSgkhTx8JhUhFPPhKXna6 qAnKUmUv9r/Ocbld330pjSYhan9ZrBn90fMswzFFGkxl6YfvZ/V2AWVvIcmLQE8MUVOv LKT/FpcvGCujzdg6GhWrQyzZLNI+5W3r10AGo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Gx/sfWK7RQOwUhoWCcsjhmPBNWJ/nVv9as+ArKz2/0k=; b=SCWEn+VXZ7KFkROARQlj1AJe/0Jq31GWzuRYG3g4KRgQM0J9jknSaQpYFnGmPOzB2B nRtNZzKBbxbSWAlGhMI4w90qlKXW5PP/nNIuVpdhOhBWik9Z+JPCM0cbASiBYkz1zkZV vSAYnmU0QnKaSLW7tN6FgrM807S2ERpafHcDlLxcBupY9xv7N0y8kKgA5bjuO9J/N4ka w/kFhmBCL9CHz/h/41JOO5IShgpxU8ScQ9PJh1HQjWNdA61o0XqH0pCaLNaftBSziCS2 n/lo7/QcLBRhOlM5pvCKDqblLOPi6D1GOUYoPpY3GM1ZhzTqGTaDYc4/AcNLeno55wb1 9EtQ== X-Gm-Message-State: AOAM532d0jSa4mHK2USwEuE6dxn9I/mOK8KIarntxGGqIJcWWSWSdh7G +G0wnsYEomy3MYaBh8Skl0NDs4dJnJvvD5rJCxxP3A== X-Received: by 2002:a2e:8e3b:: with SMTP id r27mr3217873ljk.466.1606476011042; Fri, 27 Nov 2020 03:20:11 -0800 (PST) MIME-Version: 1.0 References: <20201126165748.1748417-1-revest@google.com> <50047415-cafe-abab-a6ba-e85bb6a9b651@fb.com> In-Reply-To: <50047415-cafe-abab-a6ba-e85bb6a9b651@fb.com> From: KP Singh Date: Fri, 27 Nov 2020 12:20:00 +0100 Message-ID: Subject: Re: [PATCH bpf-next 1/2] bpf: Add a bpf_kallsyms_lookup helper To: Yonghong Song Cc: Florent Revest , bpf , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , Florent Revest , open list Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Nov 27, 2020 at 8:35 AM Yonghong Song wrote: > > > > On 11/26/20 8:57 AM, Florent Revest wrote: > > This helper exposes the kallsyms_lookup function to eBPF tracing > > programs. This can be used to retrieve the name of the symbol at an > > address. For example, when hooking into nf_register_net_hook, one can > > audit the name of the registered netfilter hook and potentially also > > the name of the module in which the symbol is located. > > > > Signed-off-by: Florent Revest > > --- > > include/uapi/linux/bpf.h | 16 +++++++++++++ > > kernel/trace/bpf_trace.c | 41 ++++++++++++++++++++++++++++++++++ > > tools/include/uapi/linux/bpf.h | 16 +++++++++++++ > > 3 files changed, 73 insertions(+) > > > > diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h > > index c3458ec1f30a..670998635eac 100644 > > --- a/include/uapi/linux/bpf.h > > +++ b/include/uapi/linux/bpf.h > > @@ -3817,6 +3817,21 @@ union bpf_attr { > > * The **hash_algo** is returned on success, > > * **-EOPNOTSUP** if IMA is disabled or **-EINVAL** if > > * invalid arguments are passed. > > + * > > + * long bpf_kallsyms_lookup(u64 address, char *symbol, u32 symbol_size, char *module, u32 module_size) > > + * Description > > + * Uses kallsyms to write the name of the symbol at *address* > > + * into *symbol* of size *symbol_sz*. This is guaranteed to be > > + * zero terminated. > > + * If the symbol is in a module, up to *module_size* bytes of > > + * the module name is written in *module*. This is also > > + * guaranteed to be zero-terminated. Note: a module name > > + * is always shorter than 64 bytes. > > + * Return > > + * On success, the strictly positive length of the full symbol > > + * name, If this is greater than *symbol_size*, the written > > + * symbol is truncated. > > + * On error, a negative value. > > */ > > #define __BPF_FUNC_MAPPER(FN) \ > > FN(unspec), \ > > @@ -3981,6 +3996,7 @@ union bpf_attr { > > FN(bprm_opts_set), \ > > FN(ktime_get_coarse_ns), \ > > FN(ima_inode_hash), \ > > + FN(kallsyms_lookup), \ > > /* */ > > > > /* integer value in 'imm' field of BPF_CALL instruction selects which helper > > diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c > > index d255bc9b2bfa..9d86e20c2b13 100644 > > --- a/kernel/trace/bpf_trace.c > > +++ b/kernel/trace/bpf_trace.c > > @@ -17,6 +17,7 @@ > > #include > > #include > > #include > > +#include > > > > #include > > > > @@ -1260,6 +1261,44 @@ const struct bpf_func_proto bpf_snprintf_btf_proto = { > > .arg5_type = ARG_ANYTHING, > > }; > > > > +BPF_CALL_5(bpf_kallsyms_lookup, u64, address, char *, symbol, u32, symbol_size, > > + char *, module, u32, module_size) > > +{ > > + char buffer[KSYM_SYMBOL_LEN]; > > + unsigned long offset, size; > > + const char *name; > > + char *modname; > > + long ret; > > + > > + name = kallsyms_lookup(address, &size, &offset, &modname, buffer); > > + if (!name) > > + return -EINVAL; > > + > > + ret = strlen(name) + 1; > > + if (symbol_size) { > > + strncpy(symbol, name, symbol_size); > > + symbol[symbol_size - 1] = '\0'; > > + } > > + > > + if (modname && module_size) { > > + strncpy(module, modname, module_size); > > + module[module_size - 1] = '\0'; > > In this case, module name may be truncated and user did not get any > indication from return value. In the helper description, it is mentioned > that module name currently is most 64 bytes. But from UAPI perspective, > it may be still good to return something to let user know the name > is truncated. > > I do not know what is the best way to do this. One suggestion is > to break it into two helpers, one for symbol name and another I think it would be slightly preferable to have one helper though. maybe something like bpf_get_symbol_info (better names anyone? :)) with flags to get the module name or the symbol name depending on the flag? > for module name. What is the use cases people want to get both > symbol name and module name and is it common? The use case would be to disambiguate symbols in the kernel from the ones from a kernel module. Similar to what /proc/kallsyms does: T cpufreq_gov_powersave_init [cpufreq_powersave] > > > + } > > + > > + return ret; > > +} > > + > > +const struct bpf_func_proto bpf_kallsyms_lookup_proto = { > > + .func = bpf_kallsyms_lookup, > > + .gpl_only = false, > > + .ret_type = RET_INTEGER, > > + .arg1_type = ARG_ANYTHING, > > + .arg2_type = ARG_PTR_TO_MEM, > ARG_PTR_TO_UNINIT_MEM? > > > + .arg3_type = ARG_CONST_SIZE, > ARG_CONST_SIZE_OR_ZERO? This is especially true for current format > which tries to return both symbol name and module name and > user may just want to do one of them. > > > + .arg4_type = ARG_PTR_TO_MEM, > ARG_PTR_TO_UNINIT_MEM? > > > + .arg5_type = ARG_CONST_SIZE, > ARG_CONST_SIZE_OR_ZERO? > > > +}; > > + > > const struct bpf_func_proto * > > bpf_tracing_func_proto(enum bpf_func_id func_id, const struct bpf_prog *prog) > > { > > @@ -1356,6 +1395,8 @@ bpf_tracing_func_proto(enum bpf_func_id func_id, const struct bpf_prog *prog) > > return &bpf_per_cpu_ptr_proto; > > case BPF_FUNC_bpf_this_cpu_ptr: > > return &bpf_this_cpu_ptr_proto; > > + case BPF_FUNC_kallsyms_lookup: > > + return &bpf_kallsyms_lookup_proto; > > default: > > return NULL; > > } > [...]