From mboxrd@z Thu Jan 1 00:00:00 1970 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 AD45EC433FE for ; Fri, 14 Oct 2022 16:55:48 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230506AbiJNQzq (ORCPT ); Fri, 14 Oct 2022 12:55:46 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60270 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230368AbiJNQzn (ORCPT ); Fri, 14 Oct 2022 12:55:43 -0400 Received: from mail-pf1-x449.google.com (mail-pf1-x449.google.com [IPv6:2607:f8b0:4864:20::449]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5712761106 for ; Fri, 14 Oct 2022 09:55:42 -0700 (PDT) Received: by mail-pf1-x449.google.com with SMTP id j20-20020a056a00235400b00565af23c8c2so3160839pfj.7 for ; Fri, 14 Oct 2022 09:55:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=lwQ6+sA3W7MWd0vYC/9HRNB0kdytHGubSeaFZENr5nY=; b=GVIG8x8OIpWYulN7VSMqXxVDEKoHPUOUkR+1sTLzVXThxcghyxLdwMVke3uKtdLYbl ZWwN6u60+DEMLfyE081V/ryY7alg8/yQ7heFroiJeCU8Ry4EYZL34K2PiA3jQ4+B/Z/b lttRUGdvS2KgrwID001oZQuIYNAcD9RPud0MtUIRwPCgA0U+jsRnzPpAH3HM/xBXQbvv iz2gucrGsBF9UAVNQOQ6Jrf0vqGL+gW+At4aN47DnXGv8HTBvujw2+C4sMEyapiYzN0T 6hbpFJS1BY8Z0dM3zHjXsKkngnOnc2TK2kRWP4FJOIljEaeJFRq09jv3JSZimTmLyTnu jmng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=lwQ6+sA3W7MWd0vYC/9HRNB0kdytHGubSeaFZENr5nY=; b=L6DaJIo7ek+5GDJtJYIfHkaVUnWyQ9tAXJ80f5TpS0vV1jvjVxoXtmUdF2tbGfejkj VY10aepinbBt9wzK85HYGlgyJ50XkRgTJlcBv1nX7h6TlaTEggzLngKnzVA39dgaUQVl Y+FqhtHy0xJ0J1vSpCUmP9hGNVG5zGhs9h2xjKSZ8Gm8uQQcu3MmTNoXRvZG0ESWgi5g mjHaubm4oRrXL6v6wZcQyGLU1cZmsKzgnbX67FKHE9670vxTG/5XKJEOPfkvRLIZgyvG Y9KsdbL/RAYDUqq9y1a/HXWDib4PZAUkLD2sG4vx9dnucjIiC6/pcduEdFWs0Mztmu36 LNEg== X-Gm-Message-State: ACrzQf3rt3ns9ug8EwMdMDhFmExYdLyGqVuciE5sRZ/mSSyiCGRPZOTC bD1epUm98TqirzIQCXubfcStbJk= X-Google-Smtp-Source: AMsMyM5U/qSXWm55jZSu6FKaWYtQ898xkpZOYAX7yp++hCg6q20IswAvnpoh6urdHCwwISyhttKtq+4= X-Received: from sdf.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5935]) (user=sdf job=sendgmr) by 2002:aa7:8607:0:b0:53b:13b5:2b6a with SMTP id p7-20020aa78607000000b0053b13b52b6amr6299861pfn.52.1665766541868; Fri, 14 Oct 2022 09:55:41 -0700 (PDT) Date: Fri, 14 Oct 2022 09:55:40 -0700 In-Reply-To: <04d2eb4a-7365-495a-ab74-704febac2789@app.fastmail.com> Mime-Version: 1.0 References: <20220715115559.139691-1-shaozhengchao@huawei.com> <20220914111936.19881-1-oss@lmb.io> <5a3c5ea9-d557-6070-d778-1092f3c51257@huawei.com> <04d2eb4a-7365-495a-ab74-704febac2789@app.fastmail.com> Message-ID: Subject: Re: [PATCH v4,bpf-next] bpf: Don't redirect packets with invalid pkt_len From: sdf@google.com To: Lorenz Bauer Cc: shaozhengchao , Alexei Starovoitov , Daniel Borkmann , bpf@vger.kernel.org, linux-kernel@vger.kernel.org, yuehaibing@huawei.com Content-Type: text/plain; charset="UTF-8"; format=flowed; delsp=yes Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 10/14, Lorenz Bauer wrote: > On Thu, 13 Oct 2022, at 11:44, shaozhengchao wrote: > > Sorry, I haven't fully understood your intentions yet. > > Can you explain it more detail? > I'll try! Roughly, we do the following: > 1. Create a BPF_PROG_TYPE_SOCKET_FILTER program that just returns 0 > 2. Load the program into the kernel > 3. Call BPF_PROG_RUN with data_size_in == 14 > After your bugfix, it seems like step 3 is rejected due to data_size_in > == 14. We had to increase data_size_in to 15 to > avoid this, see [0]. > This breaks user space, so it would be great if you could fix this in a > way that doesn't refuse BPF_PROG_RUN with [..] > data_size_in == 14. Since I don't understand the original problem very > well I can't tell you what the best fix is however. The problem was that we were able to generate skb with len=0 via BPF_PROG_RUN. Prohibiting those cases breaks backwards compatibility, so we either have to: a) (preferred?) accept inputs with <14, but maybe internally pad to 14 bytes to make the core stack happy b) revert the patch and instead have length checks at runtime; doesn't seem to be worth the penalty in the forwarding path because of some corner cases like these ? > 0: > https://github.com/cilium/ebpf/commit/a38fb6b5a46ab3b5639ea4d421232a10013596c0 > Thanks > Lorenz