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

Powered by blists - more mailing lists