netdev - Re: gre: minor cleanups in netlink interface

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]

Date:	Sat, 11 Oct 2008 23:03:40 +0800
From:	Herbert Xu <herbert@...dor.apana.org.au>
To:	Patrick McHardy <kaber@...sh.net>
Cc:	"David S. Miller" <davem@...emloft.net>,
	Linux Netdev List <netdev@...r.kernel.org>
Subject: Re: gre: minor cleanups in netlink interface

On Sat, Oct 11, 2008 at 04:43:03PM +0200, Patrick McHardy wrote:
>
> No, its equivalant to using memcpy.

Great.

> We don't have much precedent for rtnl_link besides VLAN (which
> does support incremental changes), but actually all other route
> netlink interfaces do support incremental changes by sending only
> a subset of the attributes. A reason for supporting this in the
> interface is that incremental userspace changes will always be
> racy because you need two seperate operations.

It is true that it is going to be racy when done in user-space,
however that's easily solved with locking.  Even if we did the
incremental change in the kernel it only helps certain kinds of
usage scenarios.  For instance, if the race is between two updates
to the local address you're still going to need synchronisation
in user-space.

Having said that, I'm certainly not against changing the interface
since you do have precedence with the other two :)

Do be warned that doing this for GRE is going to be less trivial
than the existing rtnl link interfaces.  For example, we'll need
to break down the iflags/oflags into individual bits as otherwise
you'll be back in the same situation.  It's a good thing that
there aren't too many bits in use :)

Also, for ikey/okey we'll need to introduce another attribute to
indicate their presence as well as their value.

Hmm, it seems that there is a bug in how we treat a zero key.
You can't have a tunnel with a zero key and one with no key at
the same time.

In fact my latest iproute patch has a similar problem.  You
can't unset the ikey/okey except by deleting the tunnel.  On
the other hand the old ip tunnel interface has the same bug :)

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@...dor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
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