Received: by 2002:a05:6358:a55:b0:ec:fcf4:3ecf with SMTP id 21csp3140246rwb; Fri, 20 Jan 2023 11:46:06 -0800 (PST) X-Google-Smtp-Source: AMrXdXtavXi2BVwnsTuDAF1cE22WH+1T5vhyWeHh21bQDMfqP61o/4wq0//MvD3FLMZh+M5u0IJx X-Received: by 2002:a50:ff17:0:b0:499:d208:e8f4 with SMTP id a23-20020a50ff17000000b00499d208e8f4mr16343981edu.19.1674243966501; Fri, 20 Jan 2023 11:46:06 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1674243966; cv=none; d=google.com; s=arc-20160816; b=haJ6/FLZ2oTgoxUcDsCkXRHBmu1ykwueGzPJmJToQM2ZwHdJfyEQF3WbDb0RuBdEaz dEBI+Srbp9O1is+DJuo4bVEfqwanzdFzEaFhn2/6+U453P0dhE6psPK7Z6C5/IhZqmLK krW0yTR3v+TM9zWGuf0dDRGprkWnAG9IxwAQ5A8nXGY2X8n6oew6rFQt7VZ8HqGHfQiX 7h81VRa8ykZ9ww9+3ZWnlPmftmHWIerYLOlAlrTSos0prkFupD+PxBwxW9CgEcJZKW/r o+yMBTT1MVUV78t3XmiW2W1Wagr3SE0hP74jUNBosYzxAcK0KcvKyyyFyLZao9Jf9jCl nxzg== 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 :references:in-reply-to:message-id:date:subject:cc:to:from; bh=XLylySo7R4JgpjOoJpqrUNeBZBhnsHbN5la5mr6nrKw=; b=FGPyFbDVARrvWY3eHP2vg3uWRkGXCU8YOgAuxu6RMyfLoNXVveuLZv/o3KpJgxDKln sjWMXvdVIRqCzToRJydt8MEjCRduAL3gUPItoLEPAcSXqFd6WjPj2vgc3lQs6FsWNq3s 5AOvAEFn6np11dreGlARKowfAK8pbZEM2BPFkZgSl+/8H5n/zfXbN3+iZ4B9SsVpBYRj RRPmiokG8L7ItA9GqjhV45F0x71F6WF/t0dKU1j6VGhms9mYylI0PHPtpxbgzFG3HSxg KBOcyyYa467YlXn/bJYdWyDHN5Dt2yKDdMt686kBg5ZYwOy83j8xyGdMA5bP00MydYMC ZgKQ== 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 Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id et11-20020a056402378b00b0049ea0e729bbsi3636405edb.152.2023.01.20.11.45.54; Fri, 20 Jan 2023 11:46:06 -0800 (PST) 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230281AbjATT0K (ORCPT + 50 others); Fri, 20 Jan 2023 14:26:10 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58406 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230340AbjATTZ7 (ORCPT ); Fri, 20 Jan 2023 14:25:59 -0500 Received: from mail-vs1-f50.google.com (mail-vs1-f50.google.com [209.85.217.50]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B975BD0DBE; Fri, 20 Jan 2023 11:25:43 -0800 (PST) Received: by mail-vs1-f50.google.com with SMTP id 3so6741273vsq.7; Fri, 20 Jan 2023 11:25:43 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=XLylySo7R4JgpjOoJpqrUNeBZBhnsHbN5la5mr6nrKw=; b=547YWvQyIZjWDnN20070w6V8NkO9Z8SCnG5nu2I3gZJfE7gaA58BHDPeJnQDD/9YFp j7IPEikK5BZIdhIJvvBhYnQmIQQkPZK/5r0b3lcT2eR+7D6cpLbmcnpZQNbrRwH+FnOA wgfSbEq9I0wxoMK8VqAmzq9o2AauRcSUGwCbEVeNE4/T0Avvwf6lI1Ox1knMhg4JYQ50 Z/huQBC5ygD2DWGiajgyV3ulRacdUV3hqVdYUypqPapCK9Lcw8hjK6aDmtVhJW9J3zTS 0sniC5CZzXKj6qnUssEIxj9lRkoADpdrs6j2b/8rjNfC+EeEKh/hIbZZjJYZAxlbrCNd jQng== X-Gm-Message-State: AFqh2krQhvDCid7utKHVZ8nob8CwaM3qISra1XZpuMLxRK1u7Ut1uzKs 5MOcbZ1/8Jg2H/nOVkeI4LCWOQZRRA01dhOS X-Received: by 2002:a05:6102:1517:b0:3d3:c855:bf54 with SMTP id f23-20020a056102151700b003d3c855bf54mr11263598vsv.34.1674242742092; Fri, 20 Jan 2023 11:25:42 -0800 (PST) Received: from localhost ([2620:10d:c091:480::1:2fc9]) by smtp.gmail.com with ESMTPSA id q15-20020a05620a038f00b00704a2a40cf2sm1419246qkm.38.2023.01.20.11.25.41 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 20 Jan 2023 11:25:41 -0800 (PST) From: David Vernet To: bpf@vger.kernel.org Cc: ast@kernel.org, daniel@iogearbox.net, andrii@kernel.org, martin.lau@linux.dev, song@kernel.org, yhs@meta.com, john.fastabend@gmail.com, kpsingh@kernel.org, sdf@google.com, haoluo@google.com, jolsa@kernel.org, linux-kernel@vger.kernel.org, kernel-team@meta.com, tj@kernel.org, memxor@gmail.com Subject: [PATCH bpf-next v2 9/9] bpf/docs: Document the nocast aliasing behavior of ___init Date: Fri, 20 Jan 2023 13:25:23 -0600 Message-Id: <20230120192523.3650503-10-void@manifault.com> X-Mailer: git-send-email 2.39.0 In-Reply-To: <20230120192523.3650503-1-void@manifault.com> References: <20230120192523.3650503-1-void@manifault.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00, FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS, RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS autolearn=no 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 When comparing BTF IDs for pointers being passed to kfunc arguments, the verifier will allow pointer types that are equivalent according to the C standard. For example, for: struct bpf_cpumask { cpumask_t cpumask; refcount_t usage; }; The verifier will allow a struct bpf_cpumask * to be passed to a kfunc that takes a const struct cpumask * (cpumask_t is a typedef of struct cpumask). The exception to this rule is if a type is suffixed with ___init, such as: struct nf_conn___init { struct nf_conn ct; }; The verifier will _not_ allow a struct nf_conn___init * to be passed to a kfunc that expects a struct nf_conn *. This patch documents this behavior in the kfuncs documentation page. Signed-off-by: David Vernet --- Documentation/bpf/kfuncs.rst | 43 ++++++++++++++++++++++++++++++++++++ 1 file changed, 43 insertions(+) diff --git a/Documentation/bpf/kfuncs.rst b/Documentation/bpf/kfuncs.rst index 560f4ede3a9f..7bdce4955a1b 100644 --- a/Documentation/bpf/kfuncs.rst +++ b/Documentation/bpf/kfuncs.rst @@ -247,6 +247,49 @@ type. An example is shown below:: } late_initcall(init_subsystem); +2.6 Specifying no-cast aliases with ___init +-------------------------------------------- + +The verifier will always enforce that the BTF type of a pointer passed to a +kfunc by a BPF program, matches the type of pointer specified in the kfunc +definition. The verifier, does, however, allow types that are equivalent +according to the C standard to be passed to the same kfunc arg, even if their +BTF_IDs differ . + +For example, for the following type definition: + +.. code-block:: c + + struct bpf_cpumask { + cpumask_t cpumask; + refcount_t usage; + }; + +The verifier would allow a ``struct bpf_cpumask *`` to be passed to a kfunc +taking a ``cpumask_t *`` (which is a typedef of ``struct cpumask *``). For +instance, both ``struct cpumask *`` and ``struct bpf_cpmuask *`` can be passed +to bpf_cpumask_test_cpu(). + +In some cases, this type-aliasing behavior is not desired. ``struct +nf_conn___init`` is one such example: + +.. code-block:: c + + struct nf_conn___init { + struct nf_conn ct; + }; + +The C standard would consider these types to be equivalent, but it would not +always be safe to pass either type to a trusted kfunc. ``struct +nf_conn___init`` represents an allocated ``struct nf_conn`` object that has +*not yet been initialized*, so it would therefore be unsafe to pass a ``struct +nf_conn___init *`` to a kfunc that's expecting a fully initialized ``struct +nf_conn *`` (e.g. ``bpf_ct_change_timeout()``). + +In order to accommodate such requirements, the verifier will enforce strict +PTR_TO_BTF_ID type matching if two types have the exact same name, with one +being suffixed with ``___init``. + 3. Core kfuncs ============== -- 2.39.0