netdev - Re: [PATCH net-next] openvswitch: report features supported by the kernel datapath

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: <20151009114646.2ee66f3b@griffin>
Date:	Fri, 9 Oct 2015 11:46:46 +0200
From:	Jiri Benc <jbenc@...hat.com>
To:	Thomas Graf <tgraf@...g.ch>
Cc:	Jesse Gross <jesse@...ira.com>, netdev <netdev@...r.kernel.org>,
	"dev@...nvswitch.org" <dev@...nvswitch.org>,
	Pravin Shelar <pshelar@...ira.com>
Subject: Re: [PATCH net-next] openvswitch: report features supported by the
 kernel datapath

On Fri, 9 Oct 2015 11:24:53 +0200, Thomas Graf wrote:
> On 10/08/15 at 03:40pm, Jesse Gross wrote:
> > I have similar concerns as were expressed in the other thread. The
> > features listed here aren't OVS components and I don't think that it
> > makes sense for OVS to try to cover everything that is related - the
> > goal that we've been working towards is to have OVS be less monolithic
> > and more integrated. So to the extent that it is necessary to have
> > capabilities be exposed (and I would like to avoid this where
> > possible), it should be in the individual component, not in OVS.

Fair enough. Note that the IPv6 flag really belongs to ovs, though -
it's about the existence of OVS_TUNNEL_KEY_ATTR_IPV6_SRC and
OVS_TUNNEL_KEY_ATTR_IPV6_DST netlink attributes. For the lwtunnel flag
(which is just another way to tell whether vxlan/geneve/etc. has
COLLECT_METADATA support) I can agree that it does not belong to ovs.

> I'm fine with that as well. However, I do dislike the idea of creating
> net_devices with a set of parameters just to figure if the parameters
> are supported or not. This works OK for the first step of evolution
> where we have support or not but it gets absolutely messy when we
> have: no support, multiple levels of partial support and finally full
> support.

100% agreed.

> We have been thinking about a more generic capabilities Netlink
> interface for a while and this looks like a good justification for
> finally doing that work.

I've been looking into this since morning and everything I've been able
to come up with seems to be quite intrusive. Before investing time to
create a long patchset that might be potentially rejected, I'd like to
get some opinions.

My thoughts are introducing either RTM_VALIDATELINK or
RTM_NEWLINK_STRICT. In the first case, it would just check whether the
passed attributes are okay for "strict" creation of the link; in the
second case, it would either reject the request, or create the link
(similarly to what RTM_NEWLINK does but with "strict" attributes
checking).

The "strict" checking would mean:

- Rejecting attributes with type <= 0 and > maxtype (i.e. changing
  nla_parse, nlmsg_parse, etc. to do optional strict checking based on
  a passed bool parameter).

- Adding the bool parameter for strict checking to rtnl_link_ops
  validate and slave_validate callbacks.

It would mean refactoring of rtnl_newlink.

Or do you have something more generic in mind? Like adding a new
NLM_F_REQUEST_STRICT flag to nlmsghdr to be used instead of
NLM_F_REQUEST?

Thanks,

 Jiri

-- 
Jiri Benc
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html