linux-kernel - Re: [regression] nf_iterate(), BUG: unable to handle kernel NULL pointer dereference

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <1216921639.15519.239.camel@calx>
Date:	Thu, 24 Jul 2008 12:47:19 -0500
From:	Matt Mackall <mpm@...enic.com>
To:	Herbert Xu <herbert@...dor.apana.org.au>
Cc:	Pekka Enberg <penberg@...helsinki.fi>,
	Patrick McHardy <kaber@...sh.net>, Ingo Molnar <mingo@...e.hu>,
	David Miller <davem@...emloft.net>, w@....eu,
	davidn@...idnewall.com, torvalds@...ux-foundation.org,
	akpm@...ux-foundation.org, netdev@...r.kernel.org,
	linux-kernel@...r.kernel.org, stefanr@...6.in-berlin.de,
	rjw@...k.pl, ilpo.jarvinen@...sinki.fi,
	Dave Jones <davej@...hat.com>,
	Christoph Lameter <cl@...ux-foundation.org>
Subject: Re: [regression] nf_iterate(), BUG: unable to handle kernel NULL
	pointer dereference

On Thu, 2008-07-24 at 22:37 +0800, Herbert Xu wrote:
> On Thu, Jul 24, 2008 at 08:11:49AM -0500, Matt Mackall wrote:
> >
> > You don't honestly expect people to correctly code to such a standard,
> > do you? People will assume that ksize never fails, they will be wrong,
> > and computers will die.
> 
> If we follow this argument then most of our interfaces would be
> broken.

Let's try this again: did you know that ksize could fail depending on
kernel configuration? Most of us would answer no. That suggests the API
is bad. This ranks 12 on Rusty's spectrum of user-friendly APIs:

http://ozlabs.org/~rusty/ols-2003-keynote/img51.html

> > >  You're taking
> > > away an entire interface just because an underlying implementation
> > > that's used by a very small proportion of users doesn't do the
> > > right thing.
> > 
> > Umm, no. There were very few users to being with, so it was actually a
> > fairly large proportion. And that suggested the interface was a bad
> > idea.
> 
> Huh? I'm talking about users of the kernel.  A very small proportion
> of those use SLOB.

Ahh. I see what you're saying. You may be right about that, or you may
be wrong: I don't know which of the millions of mass market embedded
Linux devices out there are using it.

And of course I argue that SLOB did do the right thing, which was only
allowing ksize on kmalloced objects. It's an accident of implementation
that kmalloc and kmem_cache_alloc use the same underlying allocator. It
has not been true at all points in the past, it's not true for some
users in the present, and it may not be true for most users in the
future. Thus, it's a bad idea to try to use ksize on something that
wasn't kmalloced.

If you have an argument for reintroducing ksize based on an actual use
case, let's please move on to (or back to) it so that we can have some
substance to this discussion.

-- 
Mathematics is the supreme nostalgia of our time.

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