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 5535F95C4F7 for ; Thu, 21 Apr 2022 18:27:54 +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=SqoKMMu2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1650558472; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=TOtejBcNLZ5DcaXPXYAL05tigOBHQkfjxArCAlT0UcQ=; b=SqoKMMu2Fp/15qnFf10uxZeHYRx4GIOsKvGkkQ5GVZhlYBvlBFe+KnOvzfKahy6wqMBHPp iDVika23WxOgMUaQOsJ5TnhkAnLK8vDGIGPqMPC+qo0/wpuPUZ5eA9Bu7z53ZB6w7FVlSY 8NQpFaoLHEViqo+oswN7sCzxaaTBTNg= Received: from mail-ej1-f72.google.com (mail-ej1-f72.google.com [209.85.218.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-509-r1RcAGjnMveExsa2UaDgVg-1; Thu, 21 Apr 2022 12:27:51 -0400 X-MC-Unique: r1RcAGjnMveExsa2UaDgVg-1 Received: by mail-ej1-f72.google.com with SMTP id gs30-20020a1709072d1e00b006f00c67c0b0so2393598ejc.11 for ; Thu, 21 Apr 2022 09:27:50 -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:message-id:date:mime-version:user-agent:cc :subject:content-language:to:references:in-reply-to :content-transfer-encoding; bh=TOtejBcNLZ5DcaXPXYAL05tigOBHQkfjxArCAlT0UcQ=; b=dXK+VLPTzD0KWn+MFmQCQzPtZp9tm89qJ1GKigwiMbPPvnLKJkpGA6K0R24HYAujC+ lnETpAVZ3PizBPo8sg1J3A+H3UXI8kp+LchOV6hQvQWy+R569TbaUjEb0tvsGraF0fXr eoXNPMK8gwNl+Iv1geWMx08FlAWnDtGLyIpJwWUtRf/t2qx3SLUiJ+YRcfZUh0nKp8OY CCdqJwF9+fKP8jBm3HwUtiXy6pJF5Ny2a27bQ1AUdG1W1i6S+kVcuuD9ho2N5o631bSh wjPJN1XhrK/xi/aiuIOMZ50dDmQ6TGugd6s6hyYvriuNeCLcKx/20Vxe5GsJvGestVeo eEVw== X-Gm-Message-State: AOAM530DFbNyi8YQy+DfQCQtOb02D0QS3jcvIBFYwCWhaQHW0yLAQkcd U9vYcwh/W+m/MH1AOFM7t9FQool83ml2QdLoHDBuMkh9fjgywzV+7p/gvB/O514Oc4+Vkjm+A3W ZfasHWYPBCEB4F5r6lbMS X-Received: by 2002:a17:906:5cb:b0:6cf:954:d84d with SMTP id t11-20020a17090605cb00b006cf0954d84dmr330075ejt.560.1650558469832; Thu, 21 Apr 2022 09:27:49 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwVXdHGccv+gnrvFUjA5eq0cPv81/PWP6CCf7Wg6ao1loaIbrfFS/VNN4FhXEhpiPKT4AxYPg== X-Received: by 2002:a17:906:5cb:b0:6cf:954:d84d with SMTP id t11-20020a17090605cb00b006cf0954d84dmr330042ejt.560.1650558469574; Thu, 21 Apr 2022 09:27:49 -0700 (PDT) Received: from [192.168.0.50] (87-59-106-155-cable.dk.customer.tdc.net. [87.59.106.155]) by smtp.gmail.com with ESMTPSA id r3-20020aa7cb83000000b0041b573e2654sm11582246edt.94.2022.04.21.09.27.47 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 21 Apr 2022 09:27:49 -0700 (PDT) From: Jesper Dangaard Brouer X-Google-Original-From: Jesper Dangaard Brouer Message-ID: Date: Thu, 21 Apr 2022 18:27:47 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.2.0 To: Larysa Zaremba , bpf References: <20220421155620.81048-1-larysa.zaremba@intel.com> In-Reply-To: <20220421155620.81048-1-larysa.zaremba@intel.com> Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=jbrouer@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Message-ID-Hash: O5GNNYR3DALFLGPZBREF55VDHSYFD4MY X-Message-ID-Hash: O5GNNYR3DALFLGPZBREF55VDHSYFD4MY X-MailFrom: jbrouer@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: brouer@redhat.com, netdev , Andrii Nakryiko , Alexei Starovoitov , Daniel Borkmann , Toke Hoiland-Jorgensen , Magnus Karlsson , Maciej Fijalkowski , Alexander Lobakin , "xdp-hints@xdp-project.net" X-Mailman-Version: 3.3.5 Precedence: list Subject: [xdp-hints] Re: Accessing XDP packet memory from the end List-Id: XDP hardware hints design discussion Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: On 21/04/2022 17.56, Larysa Zaremba wrote: > Dear all, > Our team has encountered a need of accessing data_meta in a following way: > > int xdp_meta_prog(struct xdp_md *ctx) > { > void *data_meta_ptr = (void *)(long)ctx->data_meta; > void *data_end = (void *)(long)ctx->data_end; > void *data = (void *)(long)ctx->data; > u64 data_size = sizeof(u32); > u32 magic_meta; > u8 offset; > > offset = (u8)((s64)data - (s64)data_meta_ptr); I'm not sure the verifier can handle this 'offset' calc. As it cannot statically know the sized based on this statement. Maybe this is not the issue. > if (offset < data_size) { > bpf_printk("invalid offset: %ld\n", offset); > return XDP_DROP; > } > > data_meta_ptr += offset; > data_meta_ptr -= data_size; > > if (data_meta_ptr + data_size > data) { > return XDP_DROP; > } > > magic_meta = *((u32 *)data); > bpf_printk("Magic: %d\n", magic_meta); > return XDP_PASS; > } > > Unfortunately, verifier claims this code attempts to access packet with > an offset of -2 (a constant part) and negative offset is generally forbidden. Are you forgetting to mention: - Have you modified the NIC driver to adjust data_meta pointer and provide info in this area? p.s. this is exactly what I'm also working towards[1], so I'll be happy to collaborate. I'm missing the driver code, as link[1] is focused on decoding BTF data_meta area in userspace for AF_XDP. [1] https://github.com/xdp-project/bpf-examples/tree/master/AF_XDP-interaction > For now we have 2 solutions, one is using bpf_xdp_adjust_meta(), > which is pretty good, but not ideal for the hot path. > The second one is the patch at the end. > Are you saying, verifier cannot handle that driver changed data_meta pointer and provided info there (without calling bpf_xdp_adjust_meta)? > Do you see any other way of accessing memory from the end of data_meta/data? > What do you think about both suggested solutions? > > Best regards, > Larysa Zaremba > > --- > > --- a/kernel/bpf/verifier.c > +++ b/kernel/bpf/verifier.c > @@ -3576,8 +3576,11 @@ static int check_packet_access(struct bpf_verifier_env *env, u32 regno, int off, > } > > err = reg->range < 0 ? -EINVAL : > - __check_mem_access(env, regno, off, size, reg->range, > - zero_size_allowed); > + __check_mem_access(env, regno, off + reg->smin_value, size, > + reg->range + reg->smin_value, zero_size_allowed); > + err = err ? : > + __check_mem_access(env, regno, off + reg->umax_value, size, > + reg->range + reg->umax_value, zero_size_allowed); > if (err) { > verbose(env, "R%d offset is outside of the packet\n", regno); > return err; >