[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180307101014.GG11750@eros>
Date: Wed, 7 Mar 2018 21:10:14 +1100
From: "Tobin C. Harding" <tobin@...orbit.com>
To: Kees Cook <keescook@...omium.org>
Cc: "Tobin C. Harding" <me@...in.cc>,
Kernel Hardening <kernel-hardening@...ts.openwall.com>,
Tycho Andersen <tycho@...ho.ws>,
Oleg Drokin <oleg.drokin@...el.com>,
Andreas Dilger <andreas.dilger@...el.com>,
James Simmons <jsimmons@...radead.org>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Subject: Re: [RFC 2/2] lustre: use VLA_SAFE
On Tue, Mar 06, 2018 at 09:46:02PM -0800, Kees Cook wrote:
> On Tue, Mar 6, 2018 at 9:27 PM, Tobin C. Harding <me@...in.cc> wrote:
> > Currently lustre uses a VLA to store a string on the stack. We can use
> > the newly define VLA_SAFE macro to make this declaration safer.
> >
> > Use VLA_SAFE to declare VLA.
>
> VLA_SAFE implements a max, which is nice, but I think we're just
> digging ourselves into a bigger hole with this, since now all the
> maxes must be validated (which isn't done here, what happens if
> VLA_DEFAULT_MAX is smaller than the strlen() math? We'll overflow the
> stack buffer in the later sprintf).
ok, lets drop this.
Memory on the stack is always going to be faster than memory from the
slub allocator, right? Do you think using kasprintf() is going to be
acceptable? Isn't it only going to be acceptable on non-time critical
paths? I'm still trying to get my head around how we get rid of VLA
when the stack is faster? Is this a speed vs safety trade off that must
be tackled on a case by case basis?
thanks,
Tobin.
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
