Received: by 2002:a05:6358:16cd:b0:dc:6189:e246 with SMTP id r13csp1617016rwl; Fri, 4 Nov 2022 16:46:35 -0700 (PDT) X-Google-Smtp-Source: AMsMyM5JLXr5SKVD/CgE2lWVWk2Cx4PY1dkq8l3LryuMLEl616edVmUC04MlDURR0YwrFEdemh4V X-Received: by 2002:a17:907:a42c:b0:7aa:97e5:fac6 with SMTP id sg44-20020a170907a42c00b007aa97e5fac6mr36080020ejc.378.1667605595199; Fri, 04 Nov 2022 16:46:35 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1667605595; cv=none; d=google.com; s=arc-20160816; b=1FDDarpXMazti2ouGyXfAXSCzCoLhjib1KKTOi6jALuS8T3SGnqB6c6Gncc8CutSW5 pKrSSb1eNFgpP3Ssf+5wfjCINNt30OVZSTg8iDosLHrATDMe4iuvep9VTwsIHdo9C7lY HEXBHJsBhcZzLML+FXEW18HNEMSv3wAnYpzxSeU6LiwgLLXFXzwWG825niQZW20ZimVp LDvbqodik/kOAz5wuOdmCSYgM0d7qzDLZNkKs2KOddNlQOgzIsDS/00bdUp8Il9CAYc2 Qlb+Rk++j/oTB9P9eGQJkGdZ2Pz8IW9NiZN5TNP/3tVwJQXlgy2saH2xqqK57/CayDQX D8kA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=gPS2+UU8iwApZPhZmjyMJQFgHkJsGSiJkrP0Ew3CwIY=; b=Xmyxgn8Pim2g5wv23Q271paKSx+v5P34WwY2FKB75TjYlR84V6ZKr2QYSM2ddpmKYO XDPq8xRlKNuP4cmU2DyJm84yM2fr4OBIFkoEFL/JjkSj+0rrketNKNtFJ/8l6l0fC94+ o/BXngCG6b6A6B9GhiZIOB6RSljBBxIhveGIfWVIpBMbyINbGvLgnS76h0ZeK2ITUFXL X6SagIw72cuXPGuB90DchAS2G7bOjaKUZ+8/AphXz17zXdgDO3jfR3MOaO1Z/INtQiC+ 6kthSw6zK9KEJBWAqfUGcfrtJ+cciTnV0Tep9KSOLu/YiqW7fx0srZYnQQawVZNFvaTd ChyA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=BmQGcD73; 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=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id m17-20020a056402511100b00461b8e2c7f4si1072969edd.548.2022.11.04.16.46.11; Fri, 04 Nov 2022 16:46:35 -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; dkim=pass header.i=@gmail.com header.s=20210112 header.b=BmQGcD73; 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=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229542AbiKDXcm (ORCPT + 97 others); Fri, 4 Nov 2022 19:32:42 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55056 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229477AbiKDXck (ORCPT ); Fri, 4 Nov 2022 19:32:40 -0400 Received: from mail-ej1-x634.google.com (mail-ej1-x634.google.com [IPv6:2a00:1450:4864:20::634]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8D246BCAD; Fri, 4 Nov 2022 16:32:39 -0700 (PDT) Received: by mail-ej1-x634.google.com with SMTP id q9so17171827ejd.0; Fri, 04 Nov 2022 16:32:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=gPS2+UU8iwApZPhZmjyMJQFgHkJsGSiJkrP0Ew3CwIY=; b=BmQGcD73WnyuFV/7Pot3nedscTK62DmVc12N4FcDIvImStdkUFZDh4hZKO42rJ02Zu VMh/FVUD2QZzfxs2GllIlzAsqUMvC5HMksiSH2/rCUDlA9/eDNkGNzDy47YkJC6xlPAY SP+xoEUHZTdosyPZx3gQFj50ks3/MU8sZyD+YLONJLEAAM0rSqAdbaNeXn2CBJQYpoyi sZwlIOIZb7L3D0HWBtJcUxj7mPzL5HHrkb8vI5z5mAxXVKEeaMdWYYLI9kT+ZdT8feen 3GNFHA3T42qODuwdCwkWYcgXOHnmsqof+oJCtdQKuwMGW60Ta8JFD2pm2n+3D9+1Ha0s 1kwg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=gPS2+UU8iwApZPhZmjyMJQFgHkJsGSiJkrP0Ew3CwIY=; b=i+/HHn9sxMqkqfJit+MZ8fpxmkhgbpvGBFEp90rGNGvjB+u/wPvs38BD+8gIppZqWI R0iMBaDC2i3E1Fo0f36yHex2UVNqazmPz8YK7HpvNIQrMS5DxxHDf+0AWS1nRAR9HISn OhQK7Q+tZY49QnrFwFQDTali0YNEt5m0cbR06VE2wLUZMdGoRlnWnlnnCN12GFhclaEs vOwaLFw9EUmG7ynWLgy5BcawXp4EukWjEdLLs7Jwin0JrL/f0AgZu5UgC3EImE6gxAVb tHb/2mCXfO9BM93xROyreMOUsGOZr/KMHYDseI1FFR+eAjVMYMha7VV7E4I/JhZRUzOl NHPQ== X-Gm-Message-State: ACrzQf0AI6bpoBTBTbuWuhHspZpFdPDhmOKZdrou5DZkCtDs371ZJc7v VzVdMyKhzmeLiESZKdUC54uPgdwlfsgKyaVuGeY= X-Received: by 2002:a17:906:8a73:b0:7ae:3962:47e7 with SMTP id hy19-20020a1709068a7300b007ae396247e7mr4500472ejc.502.1667604758005; Fri, 04 Nov 2022 16:32:38 -0700 (PDT) MIME-Version: 1.0 References: <20221103083254.237646-1-yangjihong1@huawei.com> <20221103083254.237646-3-yangjihong1@huawei.com> In-Reply-To: From: Alexei Starovoitov Date: Fri, 4 Nov 2022 16:32:26 -0700 Message-ID: Subject: Re: [PATCH 2/4] bpf: Remove size check for sk in bpf_skb_is_valid_access for 32-bit architecture To: Andrii Nakryiko Cc: Yang Jihong , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , Martin KaFai Lau , Song Liu , Yonghong Song , John Fastabend , KP Singh , Stanislav Fomichev , Hao Luo , Jiri Olsa , Shubham Bansal , Russell King , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Mykola Lysenko , Shuah Khan , Benjamin Tissoires , Kumar Kartikeya Dwivedi , Delyan Kratunov , Artem Savkov , colin.i.king@gmail.com, bpf , linux-arm-kernel , LKML , Network Development , "open list:KERNEL SELFTEST FRAMEWORK" Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS 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 On Fri, Nov 4, 2022 at 2:56 PM Andrii Nakryiko wrote: > > On Thu, Nov 3, 2022 at 1:36 AM Yang Jihong wrote: > > > > The error code -EACCES is returned when bpf prog is tested in 32-bit environment, > > This is because bpf_object__relocate modifies the instruction to change memory > > size to 4 bytes, as shown in the following messages: > > > > libbpf: prog 'kfunc_call_test1': relo #2: matching candidate #0 [18342] struct __sk_buff.sk (0:30:0 @ offset 168) > > libbpf: prog 'kfunc_call_test1': relo #2: patched insn #1 (LDX/ST/STX) off 168 -> 168 > > libbpf: prog 'kfunc_call_test1': relo #2: patched insn #1 (LDX/ST/STX) mem_sz 8 -> 4 > > > > As a result, the bpf_skb_is_valid_access check fails. For 32-bit architecture, > > unnecessary checks need to be deleted. > > > > Signed-off-by: Yang Jihong > > --- > > net/core/filter.c | 2 -- > > 1 file changed, 2 deletions(-) > > > > diff --git a/net/core/filter.c b/net/core/filter.c > > index bb0136e7a8e4..eab7ce89740c 100644 > > --- a/net/core/filter.c > > +++ b/net/core/filter.c > > @@ -8269,8 +8269,6 @@ static bool bpf_skb_is_valid_access(int off, int size, enum bpf_access_type type > > return false; > > break; > > case offsetof(struct __sk_buff, sk): > > - if (type == BPF_WRITE || size != sizeof(__u64)) > > - return false; > > this probably should be specific to host architecture bitness? I'd > imagine that size = 4 should be invalid on 64-bit arches (reading half > of the pointer is bad) Not quite. In __sk_buff the field 'sk' is defined as: __bpf_md_ptr(struct bpf_sock *, sk); so it's always 64-bit load when bpf prog reads it. In this case CO_RE shouldn't have been applied to uapi struct __sk_buff.