From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 295A4C433E0 for ; Wed, 17 Mar 2021 14:32:39 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id C38BD64F6E for ; Wed, 17 Mar 2021 14:32:38 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231913AbhCQOcH (ORCPT ); Wed, 17 Mar 2021 10:32:07 -0400 Received: from wforward1-smtp.messagingengine.com ([64.147.123.30]:34095 "EHLO wforward1-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231877AbhCQObp (ORCPT ); Wed, 17 Mar 2021 10:31:45 -0400 Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailforward.west.internal (Postfix) with ESMTP id 8F5B8243F; Wed, 17 Mar 2021 10:31:44 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute6.internal (MEProxy); Wed, 17 Mar 2021 10:31:44 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=h8YsvWm8QT/uQ/zWAAzHRUTIUcphQ2EzHqQ3tsheD zQ=; b=LXzgE8CxsZIn6a2D1qjQU5Ub8OGDNbrJqpgZaIKfvJFqaSURUiURR1cbu qMy/PiTZAjOn3XeCYCCoqQie5nQrferxBARy7Ik0UqOlcU16Ja1uit0BMx8PnF+d 6qym/G/wusSbL7musK/0biVV20dOaytS1ge9BgvNHnoB15rcdX2ZlPKLnkEgv8Wl +y9g3WLlDUjx7t/GMzQ/L0g3S9NwxR706OIPEDayjY3OlONC2LOibo+ny+PHFNZv M2AJJUiGEdYsRyPQNOaYumXWZpTpKCgBD13/1nwbLgogbPLtlWBPQLZHkTw5w+1U jeQ4kNgWXz2HSsjuBBzUIEkvYsSWg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrudefgedgieeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurheptggguffhjgffgffkfhfvofesthekmhdthhdtjeenucfhrhhomheptfgrfhgr vghlucffrghvihguucfvihhnohgtohcuoehrrghfrggvlhguthhinhhotghosehusghunh htuhdrtghomheqnecuggftrfgrthhtvghrnhepiefhtedugeetueevveekffejffffhedt keekfeejteefgfefudelkeetfffgleeunecukfhppeduledurdeliedrjeefrddvvdelne cuufhprghmkfhppfgvthifohhrkhepudeluddrleeirdejfedrvddvleenucevlhhushht vghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehrrghfrggvlhguthhinh hotghosehusghunhhtuhdrtghomh X-ME-Proxy: Received: from [10.6.3.96] (unknown [191.96.73.229]) by mail.messagingengine.com (Postfix) with ESMTPA id 9006924005D; Wed, 17 Mar 2021 10:31:41 -0400 (EDT) Content-Type: text/plain; charset=utf-8; delsp=yes; format=flowed Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) Subject: Re: [BPF CO-RE clarification] Use CO-RE on older kernel versions. From: Rafael David Tinoco In-Reply-To: Date: Wed, 17 Mar 2021 11:31:38 -0300 Cc: Arnaldo Carvalho de Melo , Vamsi Kodavanty , bpf X-Mao-Original-Outgoing-Id: 637684238.052054-6b45b567c1d5b3360dfa095b133282b9 Content-Transfer-Encoding: 8bit Message-Id: References: <20210303181457.172434-1-rafaeldtinoco@ubuntu.com> <043B1B9B-EEF7-49CD-88AF-29A2A3E97304@ubuntu.com> <67E3C788-2835-4793-8A9C-51C5D807C294@ubuntu.com> <7BEF1010-5D4A-4C6F-8059-BD18A4A9EA6F@ubuntu.com> To: Andrii Nakryiko X-Mailer: Apple Mail (2.3654.60.0.2.21) Precedence: bulk List-ID: X-Mailing-List: bpf@vger.kernel.org >> >>>> From what I see all the CO-RE relocations applied successfully (even >>>> though all the offsets stayed the same, so presumably you compiled >>>> your BPF program with vmlinux.h from the exact same kernel you are >>>> running it on?). Are you sure that vmlinux image you are providing >>>> corresponds to the actual kernel you are running on? > > FOUND the cause of the issue… > ... > > bpf_check(): > > if (log->len_total < 128 || log->len_total > UINT_MAX >> 8 || !log->level > || !log->ubuf) > > and a simple change in libbpf (mitigation of course): > > attr.log_buf = 0; > attr.log_level = 0; > attr.log_size = 0; > > before > > fd = sys_bpf_prog_load(&attr, sizeof(attr)); With instrumented kernel… no changes to libbpf or code: attr.log_buf = (nil) attr.log_level = 0 attr.log_size = 0 load_attr.log_buf = 0x7fd1c0a92010 load_attr.log_level = 0 load_attr.log_size = 16777215 libbpf: load bpf program failed: Invalid argument libbpf: failed to load program 'ip_set_create' libbpf: failed to load object 'mine_bpf' libbpf: failed to load BPF skeleton 'mine_bpf': -22 failed to load BPF object: -22 [ 27.857858] MINE: BPF_PROG_TYPE_KPROBE KERNEL VERSION ISSUE [ 27.857993] MINE: LINUX_VERSION_CODE: 266002 [ 27.858131] MINE: YOUR VERSION: 265984 2 problems here: 0) attr.kern_version - looks like for some reason attr.kern_version is different from the one running - bypassing kernel BPF_KPROBE version check, I get: 1) load_attr has log_buf and log_size but not log_level for some reason. - this triggers an issue in bpf_check() within kernel IF I bypass the BPF_KPROBE version check (kerne 4.15). NOW, If I hard-code attr.kern_version in bpf.c to: attr.kern_version = 266002; fd = sys_bpf_prog_load(&attr, sizeof(attr)); then attr.log_buf = (nil) attr.log_level = 0 attr.log_size = 0 load_attr.log_buf = (nil) load_attr.log_level = 0 load_attr.log_size = 0 Tracing... Hit Ctrl-C to end. I don’t have the 2 problems, as log_level is zeroed, together with log_buf and log_size. Any clue on why this happens ? Thank you! -rafaeldtinoco