linux-kernel - Re: Suggestion for fixing the variable length array used in the kernel.

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: <20130309223403.GZ9138@mwanda>
Date:	Sun, 10 Mar 2013 01:34:03 +0300
From:	Dan Carpenter <dan.carpenter@...cle.com>
To:	Christopher Li <sparse@...isli.org>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	Linux-Sparse <linux-sparse@...r.kernel.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: Suggestion for fixing the variable length array used in the
 kernel.

On Sat, Mar 09, 2013 at 10:10:08AM -0800, Christopher Li wrote:
> On Fri, Mar 8, 2013 at 9:39 PM, Dan Carpenter <dan.carpenter@...cle.com> wrote:
> > On Fri, Mar 08, 2013 at 04:29:22PM -0800, Andrew Morton wrote:
> >> Roughly how many instances of this are there kernel-wide?
> >>
> >
> > Around 150 on x86 allmodconfig.  They are pretty well audited.
> 
> I saw 207 on x86-64 allmodconfig. See the list that I attached.
> 

Ah.  Sorry, I'm on my laptop and my sparse output was old.

> Can you elaborate the well audited part? How it was audited?
> 

The problems is if we go over the 8k stack.  So big arrays are bad.
Also if the dynamically sized array is inside a loop then normally
GCC frees it after each iteration, but on some arches it didn't free
it until after the last iteration.

Btw, I've Smatch has cross function analysis, and I'd like to use
it here to figure out if the max size for dynamically sized arrays.
I ran into a problem:

The code looks like this:
	char buf[a];
The size expression should be an EXPR_SYMBOL, but smatch gets:
	char buf[*a];
Where the size expression is an EXPR_PREOP.

In smatch, how I use sparse is that I call sparse_keep_tokens() and
then I parse the resulting symbol list myself.  The problem is in
examine_array_type() we call get_expression_value() which changes
the symbols from normal symbols to dereferences. The call tree is:
examine_array_type()
  -> get_expression_value()
     -> __get_expression_value()
        -> evaluate_expression()
	   -> evaluate_symbol_expression() <- change happens here.

I'm not sure what to do.

regards,
dan carpenter

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/