Re: [patch][rfc] acpi: do not use kmem caches

[Nick Piggin <npiggin@suse.de>]

On Sun, Jan 04, 2009 at 11:43:55PM -0600, Skywing wrote:
> -----Original Message-----
> From: linux-acpi-owner@vger.kernel.org [mailto:linux-acpi-owner@vger.kernel.org] On Behalf Of Nick Piggin
> Sent: Sunday, January 04, 2009 11:15 PM
> To: Len Brown
> Cc: Christoph Hellwig; Alexey Starikovskiy; Pekka Enberg; Linux Memory Management List; linux-acpi@vger.kernel.org
> Subject: Re: [patch][rfc] acpi: do not use kmem caches
> 
> > > I think they are here to stay.  We are running
> > > an interpreter in kernel-space with arbitrary input,
> > > so I think the ability to easily isolate run-time memory leaks
> > > on a non-debug system is important.
> > I don't really see the connection. Or why being an interpreter is so
> > special. Filesystems, network stack, etc run in kernel with arbitrary
> > input. If kmem caches are part of a security strategy, then it's
> > broken... You'd surely have to detect bad input before the interpreter
> > turns it into a memory leak (or recover afterward, in which case it
> > isn't a leak).
> 
> I think that the purposes of these was to act as a debugging aid, for example, if there were BIOS-supplied AML that was triggering a leak.  The point being here that a network card driver has a much more well-defined set of what can happen than a fully pluggable interpreter for third party code.

It just seems like different shades to me, rather than some completely
different thing. A single network driver, maybe, but consider that untrusted
input influences a very large part of the entire network stack... Or a
filesystem.

Basically, if the data is really untrusted or likely to result in a leak,
then it should be detected and sanitized properly, rather than being allowed
to leak.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>