Received: by 2002:a05:6358:9144:b0:117:f937:c515 with SMTP id r4csp8109784rwr; Wed, 10 May 2023 18:21:11 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ6ZzZdp1oVfw1vMhBDWMEczewgRuRjsybVCJSBgl9w2ytFbkyav0Azv3sYVCXEb9hXWwBBu X-Received: by 2002:a17:902:d483:b0:1ac:896f:f655 with SMTP id c3-20020a170902d48300b001ac896ff655mr12889210plg.50.1683768070882; Wed, 10 May 2023 18:21:10 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1683768070; cv=none; d=google.com; s=arc-20160816; b=FYSuZxbIQM9VGOLdeYnc5nwYlXc8Ro9CYdGv5sA/4cEEokOzRZzcg/OsVv9XNauaaM krmm5TJBeUkmRSIZTeRWStCeUAMoYWwU1lOdfKjvMliHotcMrbDJ7p0fLJfXvDfnqVax d5qVCHKlrUoVZb9WhW+Sn69SQIvmL3zTD4j0s7IomBhldd2licYYvBXkSWPqplr2YFCj OKfV/yT99Aipf3EeDu41oxBj+EyTNEEidCW/cS5pEMJACmKttPJXUgrjpfjbuIsGgWic DDbHHAVHqunPf2nbIsRHQRzmyy+AJhZkKP1+J0HbMqMQ7B72L254N0+oandJj+hlicR0 oMHw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=glQhUr96IfsYHdFFbknYKaga/6qXtKFb6tvCMxBk3bI=; b=A2Q5nvRyUjxBAGxg7peR92pO1MGTKKz2wIPrVBqsA1gbgz29Q7t8YZAV9AwDbXRrwo E4VPktKEVR0vjWQeaoKgMkSvGKtFpISXM03/WkXHTTq+HuymJ07BZ4wlamdsknb5vtUA H0w6MBjCLyLZl8lRFeMR67IqokwUaHiKIhpys10ZpxyGIba/3Q/iNcHAlt9Sqep9Duk6 6epCrWYFgpui+nV6KCt0sCyETvwcu6QtVIZm8yiWIZCCqEKTlvk7SSzrEYNAYqy1lYCs M6o/kIVahqhrkwZn4IvgTNZ4Vep/G6Wsd4rdkXeWrMQafpdlrr7nsEpq0qcsBoY+eMh0 QWlQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20221208 header.b=sc5RqHZX; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id q6-20020a170902dac600b001ac75cbde64si5774629plx.622.2023.05.10.18.20.56; Wed, 10 May 2023 18:21:10 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20221208 header.b=sc5RqHZX; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236008AbjEKBGa (ORCPT + 99 others); Wed, 10 May 2023 21:06:30 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44828 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229461AbjEKBG2 (ORCPT ); Wed, 10 May 2023 21:06:28 -0400 Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com [IPv6:2a00:1450:4864:20::534]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 397BF19AC; Wed, 10 May 2023 18:06:27 -0700 (PDT) Received: by mail-ed1-x534.google.com with SMTP id 4fb4d7f45d1cf-50bc0117683so14213762a12.1; Wed, 10 May 2023 18:06:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1683767185; x=1686359185; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=glQhUr96IfsYHdFFbknYKaga/6qXtKFb6tvCMxBk3bI=; b=sc5RqHZXAGh+0GPEjA7e5Umr/Wv2CyK86D5gpIn6akIs3LjuFpsb2gOVZ7xipRztxI GptfJZidIh+FMyQlRGOaIdYcBom8AvDpmtQvit/aCizulJBYjNBH6Z9XRfU2UAt9XxRV YDNgND/f7A4PMv7W17sw9svjWNMsG4Fq2Armr3CMCFa8y/abVPAwafcNCCFGZDkxbYO0 CaTNPvfVyRFO/cLKT3m2ow0qVUS7/smyxUyhxcy05wdIJOIIPuHcDA2nhr2LhqFESxKZ ddR2athFDLNGunHxrtaKS/b+zTnfAAn45iiZwIJpWb1CA573M4Z+CykWMsx3o4FvJsAs sAzg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683767185; x=1686359185; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=glQhUr96IfsYHdFFbknYKaga/6qXtKFb6tvCMxBk3bI=; b=O+GKOUXAHuJ0vRkfpRtX0nr5NRifWC/qbi+Aybamv7loH/2HdhSA85h9oH4cw058IA fyMqa7r2pSPbIMjGwpyK2BMYRcJythvam735ywN58EjqZCQmJh6ABuoo1B3Dqsj3hcg5 zYGTc8TqFGEYyiHaENb13GZHbzOI9bvd6eknUsxrVnZPGrmcPqzt3Sz3o37ZN0/rC+h9 bTxJeOCz7C/s0f2qV3/shZaxdNh+QItWITAs3k9DIJdI6RSxrUWT1ojTXaRKnJ45HNW6 otJLT2aaJduiodOlyIdMeif2R1TuLLd5JtH0qPAvwxjPeWfH9SNvvk7HMEyaHbSRBZXw imVQ== X-Gm-Message-State: AC+VfDyrkHb5qW+rPY0sYUSwiqoFAKjcGMjb0JhYzall4a/CUXI+E9D6 24bsq7qzAUSIVwrkrHrbmHT09gnc3eJYTu9/j48= X-Received: by 2002:a05:6402:1a48:b0:50c:d5d:c960 with SMTP id bf8-20020a0564021a4800b0050c0d5dc960mr15858297edb.38.1683767185401; Wed, 10 May 2023 18:06:25 -0700 (PDT) MIME-Version: 1.0 References: <20230510122045.2259-1-zegao@tencent.com> <6308b8e0-8a54-e574-a312-0a97cfbf810c@meta.com> In-Reply-To: <6308b8e0-8a54-e574-a312-0a97cfbf810c@meta.com> From: Ze Gao Date: Thu, 11 May 2023 09:06:14 +0800 Message-ID: Subject: Re: [PATCH] bpf: reject blacklisted symbols in kprobe_multi to avoid recursive trap To: Yonghong Song Cc: Song Liu , Jiri Olsa , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , Martin KaFai Lau , Yonghong Song , John Fastabend , KP Singh , Stanislav Fomichev , Hao Luo , Steven Rostedt , Masami Hiramatsu , Ze Gao , bpf@vger.kernel.org, linux-kernel@vger.kernel.org, linux-trace-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_ENVFROM_END_DIGIT, FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org I'm afraid filtering in user space tools is not enough, cause it's a kernel= BUG. it would 100% trigger a kernel crash if you run cmd like retsnoop -e 'pick_next_task_fair' -a ':kernel/sched/*.c' -vvv which is caused by that BPF_LINK_TYPE_KPROBE_MULTI accidentally attaches bpf progs to preempt_count_{add, sub}, which in turn triggers stackoverflow because the handler itself calls those functions. checking in libbpf is not enough if some tools use bpf syscall directly, you know, we can not cover all cases. So kernel checking is a must, we cannot rely on users to not crash the kern= el. Thanks Ze On Wed, May 10, 2023 at 10:14=E2=80=AFPM Yonghong Song wrote= : > > > > On 5/10/23 5:20 AM, Ze Gao wrote: > > BPF_LINK_TYPE_KPROBE_MULTI attaches kprobe programs through fprobe, > > however it does not takes those kprobe blacklisted into consideration, > > which likely introduce recursive traps and blows up stacks. > > > > this patch adds simple check and remove those are in kprobe_blacklist > > from one fprobe during bpf_kprobe_multi_link_attach. And also > > check_kprobe_address_safe is open for more future checks. > > > > note that ftrace provides recursion detection mechanism, but for kprobe > > only, we can directly reject those cases early without turning to ftrac= e. > > > > Signed-off-by: Ze Gao > > --- > > kernel/trace/bpf_trace.c | 37 +++++++++++++++++++++++++++++++++++++ > > 1 file changed, 37 insertions(+) > > > > diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c > > index 9a050e36dc6c..44c68bc06bbd 100644 > > --- a/kernel/trace/bpf_trace.c > > +++ b/kernel/trace/bpf_trace.c > > @@ -2764,6 +2764,37 @@ static int get_modules_for_addrs(struct module *= **mods, unsigned long *addrs, u3 > > return arr.mods_cnt; > > } > > > > +static inline int check_kprobe_address_safe(unsigned long addr) > > +{ > > + if (within_kprobe_blacklist(addr)) > > + return -EINVAL; > > + else > > + return 0; > > +} > > + > > +static int check_bpf_kprobe_addrs_safe(unsigned long *addrs, int num) > > +{ > > + int i, cnt; > > + char symname[KSYM_NAME_LEN]; > > + > > + for (i =3D 0; i < num; ++i) { > > + if (check_kprobe_address_safe((unsigned long)addrs[i])) { > > + lookup_symbol_name(addrs[i], symname); > > + pr_warn("bpf_kprobe: %s at %lx is blacklisted\n",= symname, addrs[i]); > > So user request cannot be fulfilled and a warning is issued and some > of user requests are discarded and the rest is proceeded. Does not > sound a good idea. > > Maybe we should do filtering in user space, e.g., in libbpf, check > /sys/kernel/debug/kprobes/blacklist and return error > earlier? bpftrace/libbpf-tools/bcc-tools all do filtering before > requesting kprobe in the kernel. > > > + /* mark blacklisted symbol for remove */ > > + addrs[i] =3D 0; > > + } > > + } > > + > > + /* remove blacklisted symbol from addrs */ > > + for (i =3D 0, cnt =3D 0; i < num; ++i) { > > + if (addrs[i]) > > + addrs[cnt++] =3D addrs[i]; > > + } > > + > > + return cnt; > > +} > > + > > int bpf_kprobe_multi_link_attach(const union bpf_attr *attr, struct b= pf_prog *prog) > > { > > struct bpf_kprobe_multi_link *link =3D NULL; > > @@ -2859,6 +2890,12 @@ int bpf_kprobe_multi_link_attach(const union bpf= _attr *attr, struct bpf_prog *pr > > else > > link->fp.entry_handler =3D kprobe_multi_link_handler; > > > > + cnt =3D check_bpf_kprobe_addrs_safe(addrs, cnt); > > + if (!cnt) { > > + err =3D -EINVAL; > > + goto error; > > + } > > + > > link->addrs =3D addrs; > > link->cookies =3D cookies; > > link->cnt =3D cnt;