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 21:32:09 +0100
From:	Hannes Frederic Sowa <hannes@...essinduktion.org>
To:	Dan Williams <dcbw@...hat.com>, David Miller <davem@...emloft.net>
Cc:	lucien.xin@...il.com, netdev@...r.kernel.org
Subject: Re: [PATCHv3 net-next] ipv6: allow routes to be configured with
 expire values

On 17.12.2015 21:23, Dan Williams wrote:
> 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.

Based on your mail I started to look if we can simply publish the
nla_policy maps to user space, which get fed to nlmsg_parse. I am
working on a rtnl_annotate function which adds this information along
with a new netlink flag NLM_F_DUMP_POLICY to query those.

Right now I am struggeling with nested attributes and if it is safe to
move NLA_UNSPEC to the value 1 so we can determine if a specific
attribute is set in the policy or not...

Also nested attributes seem to be quite hairy, maybe there is no reason
to inform user space about them, I don't yet know.

This infrastructure should be safe to use also when features get backported.

Bye,
Hannes

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