Received: by 2002:a5d:9c59:0:0:0:0:0 with SMTP id 25csp2163526iof; Tue, 7 Jun 2022 21:52:25 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyClK8XhRVoKGdY4/TXeJweAEu2TdsSXO4rALjVtXS5a2wF5Fkq72jgTSPiXIwaJ5X/5vbT X-Received: by 2002:a05:6a00:2181:b0:51b:560b:dd30 with SMTP id h1-20020a056a00218100b0051b560bdd30mr46347864pfi.44.1654663945574; Tue, 07 Jun 2022 21:52:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1654663945; cv=none; d=google.com; s=arc-20160816; b=UXffKcR88NMh3C8e51vRi4y0udl5YM6wh9yUhYZzP3KKiT5dtSivPeAFH9M+TWeAS3 3BFGPXswFue1m4QqH9hSPzBR1VzFA1EX3ZXA9/UZ4ws2PmSezBFvCXoYAT8mPTy8rB0q gQZo2mh4mvkLzPfDjmv+DVuhhaEdQvLmCQmYGKwBI+gxPdFbfFo4apa2ZpBBvn3m4Be6 hq+VMzw5JNAUu7Ejho8OSWWPz1i+bCs3mzuAE2fvSCEhRZeqH1GnzVxLYIRHUBoAmxZD EhM692wTWQwVvsoByzdjSioipqhkjCZRUMNytnXKrDxuYWaxceKZqD8hh8Py6TKa6zG1 oGpg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=qr8ckUN4+kMDY5CvcfREo16W83+Aw42gay7sRERQ7ew=; b=KYciZChHldRg9icXz7+64Z3cB7ygGmGejr47jaRwcfrsY5WJYBp+uMl4Kfps+Ns6FL /6P3lOkSXecsX8nPdZ2xt5pRYA0P8Rsjj/dVueAjFc5ktkQakXBuj6EDhbBN6RK0sBUb T90EBeEOsEPqmMffjMugvCvekFxmTiJRobXImybKlXnoccxWHENI6T7WWY2vMi9jEGAw h7DDdMCpPGrcVr8GtzZGGAPs9Y+uaW+LX0VoLFPdiSiYSMCcSg6HjC3TAXBTN+V27rS8 i1an3qXlVjRjNL3Z9t/OrxP5zAYu2DIZ4njpI4CxkiMJ5YD60aT30xyGw7+x452YYJp2 OpRg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=Y2jl+YxI; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [23.128.96.19]) by mx.google.com with ESMTPS id 21-20020a630215000000b003fb10da6285si25423373pgc.741.2022.06.07.21.52.25 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 07 Jun 2022 21:52:25 -0700 (PDT) Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=Y2jl+YxI; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 483A0453206; Tue, 7 Jun 2022 21:21:55 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1359464AbiFGUY6 (ORCPT + 99 others); Tue, 7 Jun 2022 16:24:58 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58606 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1355053AbiFGTcW (ORCPT ); Tue, 7 Jun 2022 15:32:22 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A1EFE113B78; Tue, 7 Jun 2022 11:12:54 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id C0C85B82182; Tue, 7 Jun 2022 18:12:52 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 29E8AC385A2; Tue, 7 Jun 2022 18:12:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654625571; bh=GqappdJ46XNiKfc/847FHFLyVCNgfObnyezwpSKixLM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Y2jl+YxIT4p64kTCsGael6CLyK8JYuoUGnIsdvmpy60atvZ9eMJBpuJO1CiksadwE eU6T8ljSB11G3czBQ7+vlDgRM0yvPm6jnsVcB+4XSlnuOtCcJdTt1cXJXW42fg2Ibl F1JjJ+tknTMJZk3hHzDnefG2fZPhb8y33tRJsKbU= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Runqing Yang , Andrii Nakryiko , Sasha Levin Subject: [PATCH 5.17 065/772] libbpf: Fix a bug with checking bpf_probe_read_kernel() support in old kernels Date: Tue, 7 Jun 2022 18:54:17 +0200 Message-Id: <20220607164950.955107013@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220607164948.980838585@linuxfoundation.org> References: <20220607164948.980838585@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-3.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=unavailable 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 From: Runqing Yang [ Upstream commit d252a4a499a07bec21c65873f605c3a1ef52ffed ] Background: Libbpf automatically replaces calls to BPF bpf_probe_read_{kernel,user} [_str]() helpers with bpf_probe_read[_str](), if libbpf detects that kernel doesn't support new APIs. Specifically, libbpf invokes the probe_kern_probe_read_kernel function to load a small eBPF program into the kernel in which bpf_probe_read_kernel API is invoked and lets the kernel checks whether the new API is valid. If the loading fails, libbpf considers the new API invalid and replaces it with the old API. static int probe_kern_probe_read_kernel(void) { struct bpf_insn insns[] = { BPF_MOV64_REG(BPF_REG_1, BPF_REG_10), /* r1 = r10 (fp) */ BPF_ALU64_IMM(BPF_ADD, BPF_REG_1, -8), /* r1 += -8 */ BPF_MOV64_IMM(BPF_REG_2, 8), /* r2 = 8 */ BPF_MOV64_IMM(BPF_REG_3, 0), /* r3 = 0 */ BPF_RAW_INSN(BPF_JMP | BPF_CALL, 0, 0, 0, BPF_FUNC_probe_read_kernel), BPF_EXIT_INSN(), }; int fd, insn_cnt = ARRAY_SIZE(insns); fd = bpf_prog_load(BPF_PROG_TYPE_KPROBE, NULL, "GPL", insns, insn_cnt, NULL); return probe_fd(fd); } Bug: On older kernel versions [0], the kernel checks whether the version number provided in the bpf syscall, matches the LINUX_VERSION_CODE. If not matched, the bpf syscall fails. eBPF However, the probe_kern_probe_read_kernel code does not set the kernel version number provided to the bpf syscall, which causes the loading process alwasys fails for old versions. It means that libbpf will replace the new API with the old one even the kernel supports the new one. Solution: After a discussion in [1], the solution is using BPF_PROG_TYPE_TRACEPOINT program type instead of BPF_PROG_TYPE_KPROBE because kernel does not enfoce version check for tracepoint programs. I test the patch in old kernels (4.18 and 4.19) and it works well. [0] https://elixir.bootlin.com/linux/v4.19/source/kernel/bpf/syscall.c#L1360 [1] Closes: https://github.com/libbpf/libbpf/issues/473 Signed-off-by: Runqing Yang Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20220409144928.27499-1-rainkin1993@gmail.com Signed-off-by: Sasha Levin --- tools/lib/bpf/libbpf.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c index 94a6a8543cbc..41515a770e3a 100644 --- a/tools/lib/bpf/libbpf.c +++ b/tools/lib/bpf/libbpf.c @@ -4564,7 +4564,7 @@ static int probe_kern_probe_read_kernel(void) }; int fd, insn_cnt = ARRAY_SIZE(insns); - fd = bpf_prog_load(BPF_PROG_TYPE_KPROBE, NULL, "GPL", insns, insn_cnt, NULL); + fd = bpf_prog_load(BPF_PROG_TYPE_TRACEPOINT, NULL, "GPL", insns, insn_cnt, NULL); return probe_fd(fd); } -- 2.35.1