netdev - Re: [PATCH net-next 0/2] bridge: mdb: add support for extended attributes

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: <56C62ECE.6000900@cumulusnetworks.com>
Date:	Thu, 18 Feb 2016 21:51:26 +0100
From:	Nikolay Aleksandrov <nikolay@...ulusnetworks.com>
To:	David Miller <davem@...emloft.net>, razor@...ckwall.org
Cc:	netdev@...r.kernel.org, roopa@...ulusnetworks.com,
	stephen@...workplumber.org
Subject: Re: [PATCH net-next 0/2] bridge: mdb: add support for extended
 attributes

On 02/18/2016 09:37 PM, David Miller wrote:
> From: Nikolay Aleksandrov <razor@...ckwall.org>
> Date: Tue, 16 Feb 2016 12:46:52 +0100
> 
>> Note that the reason we can't simply add an attribute after
>> MDBA_MDB_ENTRY_INFO is that current users (e.g. iproute2) walk over
>> the attribute list directly without checking for the attribute type.
> 
> Honestly that sounds like a bug in iproute2 to me...
> 

I agree, but changing this in the kernel would make older iproute2 versions
incompatible with newer kernels, possibly outputting garbage from the additional
attributes, besides we still will have to turn MDBA_MDB_ENTRY_INFO into a nested
attribute and insert the struct with a header as that's the per-mdb entry attribute
currently.

Alternatively I have a version that uses a request flag in the dump request and
sends back an alternative/"extended" version of the mdbs where every field is
a netlink attribute and is extensible, thus keeping the old format in place
and offering extended attribute support to anyone who requests it.

I just thought this version is a middle ground between the two solutions and
still doesn't break user-space while being extensible.

There're no more holes in the mdb entry struct to reuse.. :-)

Cheers,
 Nik