netdev - Re: [PATCHv3 net-next] ipv6: allow routes to be configured with expire values

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:	Thu, 17 Dec 2015 14:23:57 -0600
From:	Dan Williams <dcbw@...hat.com>
To:	David Miller <davem@...emloft.net>
Cc:	lucien.xin@...il.com, netdev@...r.kernel.org,
	hannes@...essinduktion.org
Subject: Re: [PATCHv3 net-next] ipv6: allow routes to be configured with
 expire values

On Thu, 2015-12-17 at 15:08 -0500, David Miller wrote:
> From: Dan Williams <dcbw@...hat.com>
> Date: Wed, 16 Dec 2015 11:03:52 -0600
> 
> > On Wed, 2015-12-16 at 17:50 +0800, Xin Long wrote:
> >> Add the support for adding expire value to routes,  requested by
> >> Tom Gundersen <teg@...m.no> for systemd-networkd, and
> NetworkManager
> >> wants it too.
> >> 
> >> implement it by adding the new RTNETLINK attribute RTA_EXPIRES.
> > 
> > Could you also add bits to send RTA_EXPIRES back to userspace in
> the
> > route dump in rt6_fill_node(), so that userspace can figure out
> when
> > RTA_EXPIRES is supported or not?
> > 
> > (obviously having it there isn't foolproof as if there are no
> routes on
> > the system yet userspace can't figure out support, but it's better
> than
> > nothing...)
> 
> That brings up an interesting issue, and I do not agree that we
> should
> publish the value for the purpose of determining if the kernel
> supports
> it or not.

That said, userspace still needs to read back the EXPIRES attribute, if
only for iproute.  The program setting RTA_EXPIRES isn't the only thing
that wants to know about the route's details.

> We need to come up with a policy for handling unknown attributes
> because what we do now doesn't work.

Definitely agree.

> I'm almost positive that the right thing to do is to unilaterally
> making nlmsg_parse() error out on out-of-range attribute type
> numbers,
> and then backport that to all -stable branches.

This works for one attribute because then userspace gets an error like
EOPNOTSUPP or something.  But which attribute caused it?  Does
userspace then have to retry the operation a couple times with all the
different combinations of potentially unsupported options?

If we're going to error out on unrecognized options, I'd really like to
see some kind of netlink features bitmap or something that positively
indicates which options the kernel will accept.

Dan
--
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