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: <1461137540.2176.5.camel@sipsolutions.net>
Date:	Wed, 20 Apr 2016 09:32:20 +0200
From:	Johannes Berg <johannes@...solutions.net>
To:	David Ahern <dsa@...ulusnetworks.com>,
	David Miller <davem@...emloft.net>
Cc:	eric.dumazet@...il.com, roopa@...ulusnetworks.com,
	netdev@...r.kernel.org, jhs@...atatu.com, tgraf@...g.ch,
	nicolas.dichtel@...nd.com, egrumbach@...il.com
Subject: Re: [PATCH net-next v5] rtnetlink: add new RTM_GETSTATS message to
 dump link stats

On Tue, 2016-04-19 at 19:53 -0600, David Ahern wrote:
> 
> The kernel can set a flag in the response that it acknowledges the
> new  attribute/flag. I did that for filtering neigh dumps --
> 21fdd092acc7.
> 

Hm, that works, but I think it requires writing extra code, which I was
kinda trying to avoid. With the patch that Emmanuel wrote, we can
restrict the changes to just nla_parse().

Anyway, I think we just have to document the behaviour very precisely,
and userspace can make its own decisions.

Essentially, apps will have a number of choices:

1) Use the new attribute flag only with commands known to have been
   added after the kernel support was added.

2) Use the new attribute flag with some required attribute for
   existing commands, so that older kernel will not find the required
   attribute and will reject the operation entirely.
   May or may not fall back to trying the operation again without the
   flag.

3) Simply use the new flag and do unexpected things on kernels not
   supporting the rejection mechanism - not much worse than today in
   many cases.

I guess we'll write a proper commit message and send the patch.

johannes

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ