linux-kernel - Re: RFC - size tool for kernel build system

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: <20081009160347.GB17179@logfs.org>
Date:	Thu, 9 Oct 2008 18:03:47 +0200
From:	Jörn Engel <joern@...fs.org>
To:	Adrian Bunk <bunk@...nel.org>
Cc:	Tim Bird <tim.bird@...sony.com>,
	linux-embedded <linux-embedded@...r.kernel.org>,
	linux kernel <linux-kernel@...r.kernel.org>
Subject: Re: RFC - size tool for kernel build system

On Thu, 9 October 2008 18:21:51 +0300, Adrian Bunk wrote:
> 
> The building blocks that would be useful are IMHO:
> - a make target that generates a report for one kernel
>   (like the checkstack or export_report targets)
> - a script that compares two such reports and outputs the
>   size differences
> 
> That's also easy to do, and if that's what's wanted I can send a patch 
> that does it.
> 
> Everything else is IMHO overdesigned.

Please do.

> The real problem is that dumping some scripts into the kernel sources 
> or publishing some data on a webpage doesn't make people use them.
> 
> Like if you run "make checkstack" on the kernel today you can see that 
> drivers allocate arrays > 1 kB on the stack despite checkstack being 
> available...

Funny you should mention that.  Yesterday I noticed that make checkstack
had been ported to five more architectures since my last look at the
code.  It doesn't seem likely that those ports were required by some
pointy-haired boss for feature-completeness.  Someone must actually be
using it.

The very beauty of make checkstack is that you don't even notice whether
it is being used or not.  You point to some drivers that apparently
didn't use it, which is fine.  But how many drivers _did_ use it?  How
many problems have been solved before the patches have ever been posted
for review?  Noone knows.  And that is a good thing.  We want the
problems to get solved and not become visible in the first place.

Bloatwatch imo has the design flaw that it is a central tool hosted on
some server somewhere and only documents the damage once it has
happened.  It would be much better if every developer could run
something simple locally and clean up the mess before anyone else
notices.

I partially agree with you in one point.  It would be even better if
checkstack, bloatcheck, etc. were run automatically on every kernel
compile and developers were forced to look at any problems that come up.
But that would increase compile time, which is bad.  So there needs to
be an off button as well, as there is for sparse - where off is the
default.

Jörn

-- 
But this is not to say that the main benefit of Linux and other GPL
software is lower-cost. Control is the main benefit--cost is secondary.
-- Bruce Perens
--
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/