linux-kernel - Re: [patch 2/4] Configure out file locking features

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:	Thu, 31 Jul 2008 10:32:20 -0700
From:	Tim Bird <tim.bird@...sony.com>
To:	Adrian Bunk <bunk@...nel.org>
CC:	Thomas Petazzoni <thomas.petazzoni@...e-electrons.com>,
	linux-kernel@...r.kernel.org, linux-embedded@...r.kernel.org,
	michael@...e-electrons.com, Matt Mackall <mpm@...enic.com>,
	matthew@....cx, linux-fsdevel@...r.kernel.org,
	akpm@...ux-foundation.org
Subject: Re: [patch 2/4] Configure out file locking features

Adrian Bunk wrote:
> And for embedded systems with which applications is it 100% safe to 
> disable this option?

Sony's digital cameras.

This option *is* disabled in the kernel for (most) Sony digital cameras.
Those digital cameras have the kernel, busybox, a custom C library,
and one proprietary application.   The application does not use
flock() (or AIO, or ethtool or multi-cast)

These cameras were heavily tested, and are shipping now.  I can't
make any guarantees for other developers, but those of us who
are careful about our application development would like the option
to eliminate completely unused features from the kernel.  (And
the C library, but that's a different issue.)

> And don't answer "doesn't use flock()", I want a real-life example of a 
> device where you could guarantee a developer that disabling this option 
> in his product would be safe.

I'm not sure why a guarantee is required that other developers
use this option safely.  Maybe this is a point of disconnect between
embedded folks and non-embedded folks.  We're accustomed to making
tradeoff decisions that only affect our product, and which
we take full responsibility for testing.

If warnings or support avoidance for the general population using
such config options is the issue, I think that David Woodhouse's
suggestion that such things could taint the kernel is an interesting
idea. Maybe have we could have an "unsafe-config" taint flag?

I should add that I am sympathetic with the larger issue you raise
about nibbling at the bottom with patches that only address a
few KB of the problem, while the size continues to build (to an
even greater degree) with each release.  My response is that I agree
with you on the nibbling bit, but probably just at a different
level of KB savings.

That is, I presume you'd be OK with something that saved 100K or
even 20K, but balk at bit at these patches, which save 10k or less.
My threshold is lower (probably down to about 5K, so these are
pretty close to the bubble), but even I wouldn't recommend
applying anything much below that.  We've already started
considering to drop some linux-tiny patches that just don't save
enough to warrant continued maintenance.
 -- Tim

=============================
Tim Bird
Architecture Group Chair, CE Linux Forum
Senior Staff Engineer, Sony Corporation of America
=============================

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