netdev - Re: [PATCH net-next v3 4/4] net: tun: track dropped skb via kfree_skb

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <41d055e3-9d88-bc43-cb3b-bd67ab071e11@gmail.com>
Date:   Fri, 25 Feb 2022 08:48:00 -0700
From:   David Ahern <dsahern@...il.com>
To:     Menglong Dong <menglong8.dong@...il.com>, dongli.zhang@...cle.com
Cc:     andrii@...nel.org, ast@...nel.org, bpf@...r.kernel.org,
        daniel@...earbox.net, davem@...emloft.net, edumazet@...gle.com,
        imagedong@...cent.com, joao.m.martins@...cle.com,
        joe.jin@...cle.com, kuba@...nel.org, linux-kernel@...r.kernel.org,
        mingo@...hat.com, netdev@...r.kernel.org, rostedt@...dmis.org
Subject: Re: [PATCH net-next v3 4/4] net: tun: track dropped skb via
 kfree_skb_reason()

On 2/24/22 10:57 PM, Menglong Dong wrote:
>>>
>>> For tun unique filters, how about using a shortened version of the ioctl
>>> name used to set the filter.
>>>
>>
>> Although TUN is widely used in virtualization environment, it is only one of
>> many drivers. I prefer to not introduce a reason that can be used only by a
>> specific driver.
>>
>> In order to make it more generic and more re-usable (e.g., perhaps people may
>> add ebpf filter to TAP driver as well), how about we create below reasons.
>>
>> SKB_DROP_REASON_DEV_FILTER,     /* dropped by filter attached to
>> 				 * or directly implemented by a
>> 				 * specific driver
>> 				 */
>> SKB_DROP_REASON_BPF_DEV,	/* dropped by bpf directly
>> 				 * attached to a specific device,
>> 				 * e.g., via TUNSETFILTEREBPF
>> 				 */
> 
> Aren't DEV_FILTER and BPF_DEV too generic? eBPF atached to netdev can
> be many kinds, such as XDP, TC, etc.

yes.

> 
> I think that use TAP_TXFILTER instaed of DEV_FILTER maybe better?
> and TAP_FILTER->BPF_DEV. Make them similar to the name in
> __tun_chr_ioctl() may be easier for user to understand.
> 

in this case given the unique attach points and API tap in the name
seems more appropriate