netdev - Re: [PATCH 1/2 nf-next] netfilter: nft_meta: add NFT_META_BRI_VLAN

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: <20190627111809.4c64beuu7f2w6u3g@salvia>
Date:   Thu, 27 Jun 2019 13:18:09 +0200
From:   Pablo Neira Ayuso <pablo@...filter.org>
To:     wenxu@...oud.cn
Cc:     fw@...len.de, netfilter-devel@...r.kernel.org,
        netdev@...r.kernel.org
Subject: Re: [PATCH 1/2 nf-next] netfilter: nft_meta: add
 NFT_META_BRI_VLAN_PROTO support

On Thu, Jun 27, 2019 at 10:09:16AM +0800, wenxu@...oud.cn wrote:
> From: wenxu <wenxu@...oud.cn>
> 
> This patch provide a meta to get the bridge vlan proto
> 
> nft add rule bridge firewall zones counter meta br_vlan_proto 0x8100
> 
> Signed-off-by: wenxu <wenxu@...oud.cn>
> ---
>  include/uapi/linux/netfilter/nf_tables.h | 2 ++
>  net/netfilter/nft_meta.c                 | 9 +++++++++
>  2 files changed, 11 insertions(+)
> 
> diff --git a/include/uapi/linux/netfilter/nf_tables.h b/include/uapi/linux/netfilter/nf_tables.h
> index 8859535..0b18646 100644
> --- a/include/uapi/linux/netfilter/nf_tables.h
> +++ b/include/uapi/linux/netfilter/nf_tables.h
> @@ -796,6 +796,7 @@ enum nft_exthdr_attributes {
>   * @NFT_META_IIFKIND: packet input interface kind name (dev->rtnl_link_ops->kind)
>   * @NFT_META_OIFKIND: packet output interface kind name (dev->rtnl_link_ops->kind)
>   * @NFT_META_BRI_PVID: packet input bridge port pvid
> + * @NFT_META_BRI_VLAN_PROTO: packet input bridge vlan proto

Looks good.

Since this only works for the input path, should we rename these to?

NFT_META_BRI_IIFVID
NFT_META_BRI_IIFVPROTO

so we leave room for _OIF (output interface) in the future?

Apart from that, this looks good to me.