lkml.org 
[lkml]   [2011]   [Mar]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [PATCH] Make /proc/slabinfo 0400
    From
    Date
    On Sat, 2011-03-05 at 00:14 +0200, Pekka Enberg wrote:
    > On Sat, Mar 5, 2011 at 12:10 AM, Pekka Enberg <penberg@kernel.org> 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.




    \
     
     \ /
      Last update: 2011-03-06 11:19    [W:4.019 / U:2.828 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site