Received: by 2002:a05:6602:18e:0:0:0:0 with SMTP id m14csp4983711ioo; Tue, 31 May 2022 16:46:01 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxamnKN27ZTwA23LxKKWwCJgUgA29g039VMPxOsXFSeWSnzhYKt5EZY59PTS0H6EsYqvAdD X-Received: by 2002:a63:5a01:0:b0:3d8:22cb:9224 with SMTP id o1-20020a635a01000000b003d822cb9224mr54124124pgb.548.1654040760808; Tue, 31 May 2022 16:46:00 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1654040760; cv=none; d=google.com; s=arc-20160816; b=oQUs1MlIY2BYXRd5OxgeatAxnzmNcuD5mOjEHQL2LqWeQ+EGI8TEpd/xVDngU4p1RR /+WoW25d4iR/8mquBE5LRNQNOxd5JPiR2WiUYdfooPu5jw4eA9ADv+QNMi5Dq/ZJLd10 5ktZ3hXiLifkTp8Rs9ZtfvJdPmbZYwqlO0rEZp51FVToMo766wMWHSIZtJT4LGuCfEgP l/TxY6CxBD9pz5F/zcI/xD4gIcrkVKPYWg+gNYExNTYMfRguPPbD8dsDfaio6/5CysWG /tPj7u4b60b3+s4/zNK0TkJr5V6t0xhVTV7SHiWkmjGeeUC7e8xndJPs+nmXzioadyST fyng== 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 :message-id:date:subject:cc:to:from; bh=LgiYW1ddSnx+bYlsCgFib7JXNd1Iqlh44MyaiWwxLOY=; b=sToWCpqTGKql5G2PnLVwQwRQhZWWuZODboYCD4b0LD+xOkxPnjFb41yKHDPbX1x8W5 NIDwYaw5wEtjisO4F1CDOIOel+WWrROXCHP7nmZSY144mO1pInlRe1prXQkedQ/0wPh5 NsZcCa46sQArZyXsYV5/MicJ5kXoH8oPDNevi9TpN9EOFeej4jZUOs+LY8ZfTY1u4nO9 jXJqCeZR0Ej71z5yW8OVCKSqFyIR6G7NxW8jXpHZ/RoBo6l/II13puBKQzxJg0hezARG ru4/Td7r6u4+cW0Ty9Q0qUm7xDx5gNQqogtDEr1/Z21PQDSe+wEb7VCoRJsYwrl9qg40 AoEA== ARC-Authentication-Results: i=1; mx.google.com; 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=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id s26-20020a65645a000000b003fbd7285a83si98911pgv.817.2022.05.31.16.45.49; Tue, 31 May 2022 16:46:00 -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; 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=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234077AbiE3IqB (ORCPT + 99 others); Mon, 30 May 2022 04:46:01 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58224 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231675AbiE3Ipz (ORCPT ); Mon, 30 May 2022 04:45:55 -0400 Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8ED50DE9; Mon, 30 May 2022 01:45:54 -0700 (PDT) Received: from fraeml714-chm.china.huawei.com (unknown [172.18.147.226]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4LBTS85LZsz684pj; Mon, 30 May 2022 16:42:32 +0800 (CST) Received: from roberto-ThinkStation-P620.huawei.com (10.204.63.22) by fraeml714-chm.china.huawei.com (10.206.15.33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Mon, 30 May 2022 10:45:51 +0200 From: Roberto Sassu To: , , , CC: , , , , Roberto Sassu Subject: [PATCH 0/2] bpf: Retry access to a map in read-only mode Date: Mon, 30 May 2022 10:45:12 +0200 Message-ID: <20220530084514.10170-1-roberto.sassu@huawei.com> X-Mailer: git-send-email 2.25.1 MIME-Version: 1.0 Content-Transfer-Encoding: 7BIT Content-Type: text/plain; charset=US-ASCII X-Originating-IP: [10.204.63.22] X-ClientProxiedBy: lhreml753-chm.china.huawei.com (10.201.108.203) To fraeml714-chm.china.huawei.com (10.206.15.33) X-CFilter-Loop: Reflected X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H2,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 If a map is write-protected, for example by an eBPF program implementing the bpf_map security hook, some read-like operations like show and dump cannot be performed by bpftool even if bpftool has the right to do so. The reason is that bpftool sets the open flags to zero, at the time it gets a map file descriptor. The kernel interprets this as a request for full access to the map (with read and write permissions). The simple solution is to set only the necessary open flags for a requested operation, so that only those operations requiring more privileges than the ones granted by the enforcing eBPF programs are denied. There are different ways to solve the problem. One would be to introduce a new function to acquire a read-only file descriptor and use it from the functions implementing read-like operations. Or more simply, another is to attempt to get a read-only file descriptor in the original function when the first request with full permissions failed. This patch set implements the second solution in patch 1, and adds a corresponding test in patch 2. Depending on the feedback, the first solution can be implemented. Roberto Sassu (2): libbpf: Retry map access with read-only permission selftests/bpf: Add test for retrying access to map with read-only perm tools/lib/bpf/bpf.c | 5 ++ .../bpf/prog_tests/test_map_retry_access.c | 54 +++++++++++++++++++ .../selftests/bpf/progs/map_retry_access.c | 36 +++++++++++++ 3 files changed, 95 insertions(+) create mode 100644 tools/testing/selftests/bpf/prog_tests/test_map_retry_access.c create mode 100644 tools/testing/selftests/bpf/progs/map_retry_access.c -- 2.25.1