From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by mail.toke.dk (Postfix) with ESMTPS id 17B429838CC for ; Wed, 29 Jun 2022 16:20:50 +0200 (CEST) Authentication-Results: mail.toke.dk; dkim=pass (1024-bit key; unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=Sbl2fnii DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1656512449; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=FiYmpBBjlfIbeiZDsnGGJUZmzd2clNYiuFHxeXQgGzc=; b=Sbl2fniiZE+2MtGt4cv3uYoZYlFdgMaFyDNyo4yP+0zzsKRUQGTX+Gx04J2LieZvxhA/+I VprW6NhQDo/v83fwJWXg6DeTBZcwr96UWyiMf9a3O1QDq0Gvz6cBzHFEEdelciQYnZQJEb TNDcwJSMpa7ZKkmZ3dPqBH9Pc8NnnBE= Received: from mail-ej1-f69.google.com (mail-ej1-f69.google.com [209.85.218.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-383-NJ6ri4jHNza31mBlUNi86A-1; Wed, 29 Jun 2022 10:20:48 -0400 X-MC-Unique: NJ6ri4jHNza31mBlUNi86A-1 Received: by mail-ej1-f69.google.com with SMTP id qk8-20020a1709077f8800b00722fcbfdcf7so5003081ejc.2 for ; Wed, 29 Jun 2022 07:20:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:in-reply-to:references:date :message-id:mime-version; bh=FiYmpBBjlfIbeiZDsnGGJUZmzd2clNYiuFHxeXQgGzc=; b=7J4VUICX1Mojsa5xOavAvxojxMeoaRxPdBeG1ZFCKKgQ6mFJWozb+pAPeNwGBKxrfC 8dAzolIlk8Tm4npjaUPqXk6YB3zVRXJ9KnjL4Q+WorxCZVFiE1H8CF1wXg8Gel7aAIHS CpIWs9eNsTA2J7SHi2rkH+eRxMoK1t7TaYOxEEhz2lZBnJFbwhe/weEbH47j/9coHPB/ xsogtMuiSK9m8rVL5MY27vrBrUezjI1P2sFyGjFOhn2lTN1pa6du+e0Yc/Lq4CGRx5GC QyReYJ8pFLfpSXKu8YpknRUTCZ5CGJbUjcqpBfoO5DoOgLHvHgmyAqQSjAyUMThQwPM1 gfYw== X-Gm-Message-State: AJIora9JHYhPYExcO5dbGs8J+Ca69F8ukGYTKvBIu6JtvXtEdW0kqwNf vDuLoeeYaHd6TrzyBBtrHAlxRP1+YWy2j6hiKalZAmmbQJR4JI5qyAJbVuDdMYYEQnQ+JrsGtb0 tyoViCVySWlvteAFWyWXx X-Received: by 2002:a17:906:149b:b0:726:2968:e32a with SMTP id x27-20020a170906149b00b007262968e32amr3608541ejc.71.1656512446476; Wed, 29 Jun 2022 07:20:46 -0700 (PDT) X-Google-Smtp-Source: AGRyM1u+aP3pQSccdfNXYWYB8kCCDBlEwDGDLuhva5jc+VbGERRJ2DQ0PTjF2LI9MvNSsCpmK+SFLQ== X-Received: by 2002:a17:906:149b:b0:726:2968:e32a with SMTP id x27-20020a170906149b00b007262968e32amr3608478ejc.71.1656512445656; Wed, 29 Jun 2022 07:20:45 -0700 (PDT) Received: from alrua-x1.borgediget.toke.dk ([2a0c:4d80:42:443::2]) by smtp.gmail.com with ESMTPSA id g6-20020a1709064e4600b007121b22b376sm7737010ejw.105.2022.06.29.07.20.44 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 29 Jun 2022 07:20:45 -0700 (PDT) Received: by alrua-x1.borgediget.toke.dk (Postfix, from userid 1000) id 8CA16477063; Wed, 29 Jun 2022 16:20:44 +0200 (CEST) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= To: Jesper Dangaard Brouer , bpf@vger.kernel.org In-Reply-To: <165643385885.449467.3259561784742405947.stgit@firesoul> References: <165643378969.449467.13237011812569188299.stgit@firesoul> <165643385885.449467.3259561784742405947.stgit@firesoul> X-Clacks-Overhead: GNU Terry Pratchett Date: Wed, 29 Jun 2022 16:20:44 +0200 Message-ID: <87fsjna6v7.fsf@toke.dk> MIME-Version: 1.0 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=toke@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain Message-ID-Hash: ZVPY6FKKXPINAMVV72WEPXZTPM53MQEV X-Message-ID-Hash: ZVPY6FKKXPINAMVV72WEPXZTPM53MQEV X-MailFrom: toke@redhat.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: xdp-hints@xdp-project.net X-Mailman-Version: 3.3.5 Precedence: list Subject: [xdp-hints] Re: [PATCH RFC bpf-next 5/9] xdp: controlling XDP-hints from BPF-prog via helper List-Id: XDP hardware hints design discussion Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: Jesper Dangaard Brouer writes: > XDP BPF-prog's need a way to interact with the XDP-hints. This patch > introduces a BPF-helper function, that allow XDP BPF-prog's to interact > with the XDP-hints. > > BPF-prog can query if any XDP-hints have been setup and if this is > compatible with the xdp_hints_common struct. If XDP-hints are available > the BPF "origin" is returned (see enum xdp_hints_btf_origin) as BTF can > come from different sources or origins e.g. vmlinux, module or local. I'm not sure I quite understand what this origin is supposed to be good for? What is a BPF (or AF_XDP) program supposed to do with the information "this XDP hints struct came from a module?" without knowing which module that was? Ultimately, the origin is useful for a consumer to check that the metadata is in the format that it's expecting it to be in (so it can just load the data from the appropriate offsets). But to answer this, we really need a unique identifier; so I think the approach in Alexander's series of encoding the ID of the BTF structure itself into the next 32 bits is better? That way we'll have a unique "pointer" to the actual struct that's in the metadata area and can act on this. > RFC/TODO: Improve patch: Can verifier validate provided BTF on "update" > and detect if compatible with common struct??? If we have the unique ID as mentioned above, I think the kernel probably could resolve this automatically: whenever a module is loaded, the kernel could walk the BTF information from that module an simply inspect all the metadata structs and see if they contain the embedded xdp_hints_common struct. The IDs of any metadata structs that do contain the common struct can then be kept in a central lookup table and the consumption code can then simply compare the BTF ID to this table when building an SKB? As for the validation on the BPF side:n > + if (flags & HINTS_BTF_UPDATE) { > + is_compat_common = !!(flags & HINTS_BTF_COMPAT_COMMON); > + /* TODO: Can kernel validate if hints are BTF compat with common? */ > + /* TODO: Could BPF prog provide BTF as ARG_PTR_TO_BTF_ID to prove compat_common ? */ If we use the "global ID + lookup table" approach above, we don't really need to validate anything here: if the program says it's writing metadata with a format given by a specific ID, that implies compatibility (or not) as given by the ID. We could sanity-check the metadata area size, but the consumption code has to do that anyway, so I'm not sure it's worth the runtime overhead to have an additional check here? As for safety of the metadata content itself, I don't really think we can do anything to guarantee this: in any case the BPF program can pass a valid BTF ID and still write garbage values into the actual fields, so the consumption code has to do enough validation that this won't crash the kernel anyway. But this is no different from the packet data itself: XDP is basically in a position to be a MITM attacker of the network stack itself, which is why loading XDP programs is a privileged operation... -Toke