From patchwork Mon May 30 08:45:12 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Roberto Sassu X-Patchwork-Id: 12864428 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5A108C4332F for ; Mon, 30 May 2022 08:45:58 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234049AbiE3Ip4 (ORCPT ); Mon, 30 May 2022 04:45:56 -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 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 Precedence: bulk List-ID: X-Mailing-List: linux-kselftest@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