netdev - RE: [RFC V2 PATCH] rtnetlink: Fix problem with buffer allocation

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: <C5551D9AAB213A418B7FD5E4A6F30A0702F8A898@ORSMSX106.amr.corp.intel.com>
Date:	Mon, 13 Feb 2012 18:24:40 +0000
From:	"Rose, Gregory V" <gregory.v.rose@...el.com>
To:	Stephen Hemminger <shemminger@...tta.com>
CC:	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"davem@...emloft.net" <davem@...emloft.net>
Subject: RE: [RFC V2 PATCH] rtnetlink: Fix problem with buffer allocation

> -----Original Message-----
> From: netdev-owner@...r.kernel.org [mailto:netdev-owner@...r.kernel.org]
> On Behalf Of Stephen Hemminger
> Sent: Monday, February 13, 2012 9:29 AM
> To: Rose, Gregory V
> Cc: netdev@...r.kernel.org; davem@...emloft.net
> Subject: Re: [RFC V2 PATCH] rtnetlink: Fix problem with buffer allocation
> 
> On Sun, 12 Feb 2012 11:13:42 -0800
> Greg Rose <gregory.v.rose@...el.com> wrote:
> 
> > Implement a new nlattr type IFLA_EXT_MASK.  The mask is a 32 bit
> > value that can be used to indicate to the kernel that certain
> > extended ifinfo values are requested by the user application.
> > At this time the only mask value created is RTEXT_FILTER_VF to
> > indicate that the user wants the ifinfo dump to send information
> > about the VFs belonging to the interface.
> >
> > I have kept the NLM_F_EXT nlmsg_flags bit to indicate to the kernel
> > that the extended ifinfo dump filter mask is present.  It does not
> > act as the filter itself which has changed since the first submission
> > of this RFC.  Older versions of user applications won't set this
> > flag which should fix the problem of some applications not allocating
> > a large enough buffer for all the extended interface information.
> >
> > Signed-off-by: Greg Rose <gregory.v.rose@...el.com>
> 
> Is u32 going to be enough in next 5 years?

I'm not very good at predicting the future.

;^)

> Since it is TLV value it should work with bigger value;
> could you try sending a oversize attribute and code kernel to ignore
> bits it doesn't understand?

That sounds like a good idea.  While I'm carving out some new space for the dump request message I might as well allocate some extra for future requirements.  I'll increase the size of the ext space array to something like 16 or 32 u32 sized words and increase the attribute length accordingly.  That should do for a long time I suppose.

First we'll see if the associated kernel patch is going to fly or not.

Thanks,

- Greg

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