netdev - Re: [PATCH net-next v5 05/19] net: ethtool: add new ETHTOOL

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] [day] [month] [year] [list]

Message-ID: <CAG88wWa85iPJMYQtE4o_Cx3+-A-m_+wqxf2PWYTcpOvB=8_d8Q@mail.gmail.com>
Date:	Wed, 16 Dec 2015 16:26:46 -0800
From:	David Decotigny <ddecotig@...il.com>
To:	David Miller <davem@...emloft.net>
Cc:	Ben Hutchings <ben@...adent.org.uk>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"linux-api@...r.kernel.org" <linux-api@...r.kernel.org>,
	linux-mips@...ux-mips.org, fcoe-devel@...n-fcoe.org,
	Andrew Morton <akpm@...ux-foundation.org>,
	Tejun Heo <tj@...nel.org>, Eric Dumazet <edumazet@...gle.com>,
	Eugenia Emantayev <eugenia@...lanox.co.il>,
	Or Gerlitz <ogerlitz@...lanox.com>,
	Ido Shamay <idos@...lanox.com>, Joe Perches <joe@...ches.com>,
	Saeed Mahameed <saeedm@...lanox.com>,
	Govindarajulu Varadarajan <_govind@....com>,
	Venkata Duvvuru <VenkatKumar.Duvvuru@...lex.com>,
	Jeff Kirsher <jeffrey.t.kirsher@...el.com>,
	Pravin B Shelar <pshelar@...ira.com>,
	Ed Swierk <eswierk@...portsystems.com>,
	Robert Love <robert.w.love@...el.com>,
	"James E.J. Bottomley" <JBottomley@...allels.com>,
	Yuval Mintz <Yuval.Mintz@...gic.com>,
	Rasmus Villemoes <linux@...musvillemoes.dk>
Subject: Re: [PATCH net-next v5 05/19] net: ethtool: add new
 ETHTOOL_GSETTINGS/SSETTINGS API

Thanks David: you are right, we should copy back sizeof(struct
ethtool_settings) in that case and not sizeof(usettings). Sorry about
that, will fix for v6.

a few questions before sending update:
 - is this handshake reasonable? or should we have an ethtool cmd
dedicated to this kind of handshake, or should we hardcode bitmap
length once and for all (ie. 128 instead of 32 today)?
 - is it ok to have the u32[] api part of bitmap.h? I was assuming it
could be used for other ioctl/syscalls outside ethtool... but maybe
this is being too pretentious and we could keep this internal to
net/core?
 - struct inheritance is used to have the link mode bitmaps
piggybacked at end the public struct ethtool_settings. hence this
"parent" field. I'm not super proud of this, but I find relying on the
compiler more comfortable. could revise my position with a
constructor+accessors macros if you think it's preferred.


On Wed, Dec 16, 2015 at 8:38 AM, David Miller <davem@...emloft.net> wrote:
> From: David Decotigny <ddecotig@...il.com>
> Date: Mon, 14 Dec 2015 13:03:52 -0800
>
>> +static int ethtool_get_ksettings(struct net_device *dev, void __user *useraddr)
>> +{
>  ...
>> +     if (__ETHTOOL_LINK_MODE_MASK_NU32
>> +         != ksettings.parent.link_mode_masks_nwords) {
>> +             /* wrong link mode nbits requested */
>> +             memset(&ksettings, 0, sizeof(ksettings));
>> +             /* keep cmd field reset to 0 */
>> +             /* send back number of words required as negative val */
>> +             compiletime_assert(__ETHTOOL_LINK_MODE_MASK_NU32 <= S8_MAX,
>> +                                "need too many bits for link modes!");
>> +             ksettings.parent.link_mode_masks_nwords
>> +                     = -((s8)__ETHTOOL_LINK_MODE_MASK_NU32);
>
> I'm trying to understand how this can work.
>
> Supposedly, the link_mode_masks_nwords field is there so that we can
> add new link modes yet still work with tools built against any
> particular link mode list in the UAPI header files.
>
> But here you're forcing the value of link_mode_masks_nwords and then
> copying that amount back to userspace.  If the user allocated less
> space than the the link mode list in the kernel supports, we will
> overwrite past the end of the user's usettings object.
>
> You cannot unconditionally copy sizeof(usettings) back to the user,
> as store_ksettings_for_user() will do.
>
> I think you have to truncate here, copying only the array elements the
> user's structure actually has space for.  That's the only way this can
> work.
--
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