From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752048AbeADH2w (ORCPT + 1 other); Thu, 4 Jan 2018 02:28:52 -0500 Received: from mx1.redhat.com ([209.132.183.28]:55204 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750791AbeADH2v (ORCPT ); Thu, 4 Jan 2018 02:28:51 -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: <9ef537b6-fe41-639b-671f-8104461db765@redhat.com> Date: Thu, 4 Jan 2018 15:28:43 +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.39]); Thu, 04 Jan 2018 07:28:51 +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. Try to reproduce the possible issue, but looks like we are safe since we may hit -EFAULT which is returned by skb_copy_datagram_iter() before. So in V2, I will keep the code as is except trim 4 more bytes if vlan tag is present. Thanks