Received: by 2002:a05:6358:111d:b0:dc:6189:e246 with SMTP id f29csp2048605rwi; Thu, 3 Nov 2022 12:02:25 -0700 (PDT) X-Google-Smtp-Source: AMsMyM4f1XepaBcUIBJGNsL6LTYjU6l4Y3kP3X/p0iJ6aq5hLkWj7AlQCpljDtNgkQZ50XTUokxo X-Received: by 2002:a17:906:dc93:b0:7ad:ca82:4cb9 with SMTP id cs19-20020a170906dc9300b007adca824cb9mr23875811ejc.521.1667502145404; Thu, 03 Nov 2022 12:02:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1667502145; cv=none; d=google.com; s=arc-20160816; b=fCA5Od7jSKBfRTmtZDbl6ULpL0JcSOhBf7AVVZwcBTPO73Knb/tRRxYqW4BYCfwQBm au7v876q15IAvgCuzi0mcZJZbBOQlQzQagT3BrSCQm7XAWgJ/ozRqlqNtjG3QFol66EI /WaEVaXsl4mRgKiFbz3CUvn8IXJxKEZT6ag1ABfzU2+Unu9J8IMtRQ9dkFjLSaRvtTw/ IUloj3coU3ISkZVH3Y891mLlISBZdxF05s8Z8sLtt1A8Kat1D4Nq5DxXEke2uW/ipQRL A/EeIlToEgzaFMMyIolVz2HLvW8Vh/OQad/3D5yEZkQHdcvm+4kQfP+IA6kQXXxWKdXg KsjQ== 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=hpUWD+YhtOzA0jc8BXPLurYBvg3g1SF91WdxaY8kuSg=; b=knK/n7VOWVsiEg5PzfJy36a2VED6Nbzlvjf+9yGbz9T8us46UpbhbvACJQMrWhWZ7Y vhD2DnCGRb/0ROE1DvQnijbGoW0zKfY/YxfSoTrCFtrHKU5dXqXZ+ZahMXonJV31a9wZ BKuio1z/EAbS1ZKizqB15U7QaN5aglN2VhowVOOk/CIfL0lImEfveGKTm3AU91Zuq6AA FnxjCi1nl3hjMAIlETM5sYRmWA74o14C2Wz2glbmE12U03Xlm3w54gPMqj9SwBG2I33e fmK4nZJzRnvqO3bfQYcz8Rpg25Z2uRabuMwOKmvAi/3r1WH2KkepnhrFcMrW0h/DyNxS GNjA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b="piOPI/2n"; 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 g8-20020a056402090800b004617551556csi2608794edz.128.2022.11.03.12.01.59; Thu, 03 Nov 2022 12:02:25 -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="piOPI/2n"; 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 S231476AbiKCSPf (ORCPT + 97 others); Thu, 3 Nov 2022 14:15:35 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51308 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231307AbiKCSPU (ORCPT ); Thu, 3 Nov 2022 14:15:20 -0400 Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com [IPv6:2a00:1450:4864:20::52e]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 72F34167D0; Thu, 3 Nov 2022 11:15:13 -0700 (PDT) Received: by mail-ed1-x52e.google.com with SMTP id u24so4270273edd.13; Thu, 03 Nov 2022 11:15:13 -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=hpUWD+YhtOzA0jc8BXPLurYBvg3g1SF91WdxaY8kuSg=; b=piOPI/2n64inWAd4dAPDDYloRLYd4EcEp85U48/4ASGi/fj5jLAoJs32492KPRdgBW dp3qOcUzC1fhFBYTokF/8FHd2rTYlT1r0LmVISULPSs+nnjtgAzlLwRIn9KcjLc4lKB5 wdFHeDQiF20z5fGWlJYNSl+VyQqga7HpIoYQxfSCorbdwv+YSlLZTkhQVlVxFJhqW0fO AUUuSIUldQomKkzcyJLDPcBuL4zBVVgRNYqssM8uJT5CbzSlIlbfrPI23iT8b+eDUVnb syJh32pyHKqdCCAIWPoTJjoCxPAez1viTiZnVd8As9aSq2IFsCTx7LeFGcyifa9irud9 7aUg== 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=hpUWD+YhtOzA0jc8BXPLurYBvg3g1SF91WdxaY8kuSg=; b=xWtFah68RbXMo6eOiZF/ZJ7jc/9N4CQ9kRaYmuGZPFmqWrdMY/qG/jrGj15Ttt5Co4 cSNJ1ZSCSrJ3GBqRCsJlFsEnnzx3LYKsNRQ0rYZycnRpTh4AebuD7seZ26Kd6WZw46ik ridV1jE5mB1p92NF3u4Edts6MKRdlZWcfT70kfxGQsZKm/J0lGiFQgWKw2y7hvIMobvP Beijf8QkS2NWtNLuX5n+4f7PwUdkEMCPinaksDQpBRu4IYI9+TlC/qgPqjR3RWevbIH2 LEncqSSDLUwFnqFNm+ouOO/QpSUrW60m5JzPFWVOtgCo27QV6gtVcjls5efiEOpWYvMa DhVg== X-Gm-Message-State: ACrzQf1OyGwdMTn5BuewxLAdLwvCeY5Kim//FswUP2S5MEHhutU2bFFT a+vt88GepwW1v5itXmrlG1sUGpH8pzvJBMPL3I8= X-Received: by 2002:aa7:c6c1:0:b0:460:f684:901a with SMTP id b1-20020aa7c6c1000000b00460f684901amr31666662eds.6.1667499311857; Thu, 03 Nov 2022 11:15:11 -0700 (PDT) MIME-Version: 1.0 References: <20221103092118.248600-1-yangjihong1@huawei.com> <20221103092118.248600-3-yangjihong1@huawei.com> In-Reply-To: From: Alexei Starovoitov Date: Thu, 3 Nov 2022 11:15:00 -0700 Message-ID: Subject: Re: [PATCH bpf RESEND 2/4] bpf: Remove size check for sk in bpf_skb_is_valid_access for 32-bit architecture To: "Russell King (Oracle)" 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 , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Mykola Lysenko , Shuah Khan , Benjamin Tissoires , Kumar Kartikeya Dwivedi , Delyan Kratunov , Artem Savkov , 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 Thu, Nov 3, 2022 at 4:23 AM Russell King (Oracle) wrote: > > On Thu, Nov 03, 2022 at 05:21:16PM +0800, 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. > > Isn't the purpose of this check to ensure that the entire pointer is > written, and BPF can't write half of it? > > > > case offsetof(struct __sk_buff, sk): > > - if (type == BPF_WRITE || size != sizeof(__u64)) > > - return false; > > Wouldn't "(size != sizeof(struct bpf_sock *) && size != sizeof(__u64))" > be more appropriate here, so 32-bit can only write the 32-bit pointer > or the full 64-bit value, and 64-bit can only write the 64-bit pointer? > Or is there a reason not to? bpf folk? You're correct. The patch is completely wrong. The bug is elsewhere.