From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751406AbeACCxV (ORCPT + 1 other); Tue, 2 Jan 2018 21:53:21 -0500 Received: from mx1.redhat.com ([209.132.183.28]:48966 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751360AbeACCxG (ORCPT ); Tue, 2 Jan 2018 21:53:06 -0500 Subject: Re: [PATCH net-next 2/2] tun: allow to attach ebpf socket filter To: Willem de Bruijn Cc: Network Development , LKML , "Michael S. Tsirkin" , Willem de Bruijn References: <1514515491-6041-1-git-send-email-jasowang@redhat.com> <1514515491-6041-3-git-send-email-jasowang@redhat.com> From: Jason Wang Message-ID: <7615dc5d-fac4-73ae-c659-e2561ff501f2@redhat.com> Date: Wed, 3 Jan 2018 10:53:00 +0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.26]); Wed, 03 Jan 2018 02:53:06 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Return-Path: On 2018年01月02日 17:19, Willem de Bruijn wrote: >>> More importantly, should this program just return a boolean pass or >>> drop. Taking a length and trimming may introduce bugs later on if the >>> stack parses the packet unconditionally, expecting a minimum size >>> to be present. >>> >>> This was the reason for introducing sk_filter_trim_cap and using that >>> in other sk_filter sites. >>> >>> A quick scan shows that tun_put_user expects a full vlan tag to exist >>> if skb_vlan_tag_present(skb), for instance. If trimmed to below this >>> length the final call to skb_copy_datagram_iter may have negative >>> length. >>> >>> This is an issue with the existing sk_filter call as much as with the >>> new run_ebpf_filter call. >> Good point, so consider it was used by sk_filter too, we need to fix it >> anyway. Actually, I've considered the boolean return value but finally I >> decide to obey the style of sk filter. Maybe the trimming has real user. e.g >> high speed header recoding/analysis? Consider it's not hard to fix, how >> about just keep that? > I don't see an obvious use case, but sure. We'll just need to look > at what the minimum trim length needs to be. It looks to me that the minimum length is: skb_vlan_tag_present(skb) ? offsetof(struct vlan_ethhdr, h_vlan_proto) : 0 And consider the vlan tag insertion done in tun_put_user(), we need trim 4 more bytes if vlan tag is present. Thanks