Re: [PATCH] Make /proc/slabinfo 0400

[Matt Mackall]

On Sat, 2011-03-05 at 00:14 +0200, Pekka Enberg wrote:
> On Sat, Mar 5, 2011 at 12:10 AM, Pekka Enberg <penberg@xxxxxxxxxx> wrote:
> > I can think of four things that will make things harder for the
> > attacker (in the order of least theoretical performance impact):
> >
> >  (1) disable slub merging
> >
> >  (2) pin down random objects in the slab during setup (i.e. don't
> > allow them to be allocated)
> >
> >  (3) randomize the initial freelist
> >
> >  (4) randomize padding between objects in a slab
> >
> > AFAICT, all of them will make brute force attacks using the kernel
> > heap as an attack vector harder but won't prevent them.
> 
> There's also a fifth one:
> 
>   (5) randomize slab page allocation order
> 
> which will make it harder to make sure you have full control over a
> slab and figure out which allocation lands on it.

I think the real issue here is that it's too easy to write code that
copies too many bytes from userspace. Every piece of code writes its own
bound checks on copy_from_user, for instance, and gets it wrong by
hitting signed/unsigned issues, alignment issues, etc. that are on the
very edge of the average C coder's awareness. 

We need functions that are hard to abuse and coding patterns that are
easy to copy, easy to review, and take the tricky bits out of the hands
of driver writers.

I'm not really sure what that looks like yet, but a copy that does its
own bounds-checking seems like a start:

copy_from_user(dst, src, n, limit) # warning when limit is hit
copy_from_user_nw(dst, src, n, limit) # no warning version

-- 
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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/