netdev - Re: [PATCH net-next v2 1/3] drop_monitor: Implement namespace filtering/reporting for software drops

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: <20221123171648.486674-1-alexandr.lobakin@intel.com>
Date:   Wed, 23 Nov 2022 18:16:48 +0100
From:   Alexander Lobakin <alexandr.lobakin@...el.com>
To:     nb <nikolay.borisov@...tuozzo.com>
Cc:     Alexander Lobakin <alexandr.lobakin@...el.com>,
        nhorman@...driver.com, davem@...emloft.net, kuba@...nel.org,
        pabeni@...hat.com, netdev@...r.kernel.org, kernel@...nvz.org
Subject: Re: [PATCH net-next v2 1/3] drop_monitor: Implement namespace filtering/reporting for software drops

From: nb <nikolay.borisov@...tuozzo.com>
Date: Wed, 23 Nov 2022 18:04:25 +0200

> On 23.11.22 г. 17:33 ч., Alexander Lobakin wrote:
> > From: Nikolay Borisov <nikolay.borisov@...tuozzo.com>
> > Date: Wed, 23 Nov 2022 16:28:15 +0200
> > 
> 
> <snip>
> 
> >> @@ -1283,6 +1304,14 @@ static void net_dm_trunc_len_set(struct genl_info *info)
> >>   	net_dm_trunc_len = nla_get_u32(info->attrs[NET_DM_ATTR_TRUNC_LEN]);
> >>   }
> >>   
> >> +static void net_dm_ns_set(struct genl_info *info)
> >> +{
> >> +	if (!info->attrs[NET_DM_ATTR_NS])
> >> +		return;
> >> +
> >> +	net_dm_ns = nla_get_u32(info->attrs[NET_DM_ATTR_NS]);
> > 
> > So, if I got it correctly, it can limit the scope to only one netns.
> > Isn't that not flexible enough? What about a white- or black- list
> > of NSes to filter or filter-out?
> 
> Can do, however my current use case is to really pin-point a single 
> offending container, but yeah, you are right that a list would be more 
> flexible. I would consider doing this provided there are no blockers in 
> the code overall. Do you have any idea whether a black/white list would 
> be better? This also begs the question whether we'll support some fixed 
> amount of ns i.e an array or a list and allow an "infinite" amount of ns 
> filtering ...

I'd go with list_head to not make it limited or consume a fixed
amount of memory regardless of the actual amount of rules.

You can make it work as both white/black by having a switch
"inverse", which makes the list filtering or filtering out.

> 
> > 
> >> +}
> >> +
> >>   static void net_dm_queue_len_set(struct genl_info *info)
> >>   {
> >>   	if (!info->attrs[NET_DM_ATTR_QUEUE_LEN])
> >> @@ -1310,6 +1339,8 @@ static int net_dm_cmd_config(struct sk_buff *skb,
> >>   
> >>   	net_dm_queue_len_set(info);
> >>   
> >> +	net_dm_ns_set(info);
> >> +
> >>   	return 0;
> >>   }
> >>   
> >> @@ -1589,6 +1620,7 @@ static const struct nla_policy net_dm_nl_policy[NET_DM_ATTR_MAX + 1] = {
> >>   	[NET_DM_ATTR_ALERT_MODE] = { .type = NLA_U8 },
> >>   	[NET_DM_ATTR_TRUNC_LEN] = { .type = NLA_U32 },
> >>   	[NET_DM_ATTR_QUEUE_LEN] = { .type = NLA_U32 },
> >> +	[NET_DM_ATTR_NS]	= { .type = NLA_U32 },
> >>   	[NET_DM_ATTR_SW_DROPS]	= {. type = NLA_FLAG },
> >>   	[NET_DM_ATTR_HW_DROPS]	= {. type = NLA_FLAG },
> >>   };
> >> -- 
> >> 2.34.1
> > 
> > Thanks,
> > Olek

Thanks,
Olek