lkml.org 
[lkml]   [2012]   [Jan]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: [RFC] syscalls, x86: Add __NR_kcmp syscall
    Date
    Cyrill Gorcunov <gorcunov@gmail.com> writes:

    > On Wed, Jan 18, 2012 at 03:29:50PM -0800, Eric W. Biederman wrote:
    >> >
    >> > It doesn't matter. Even if we take a list of objects the kernel either
    >> > should return us some ordering info or find duplicates, in any case it
    >> > makes things more complex i think. So we wanted to bring some minimum
    >> > into kernel leaving the rest of work to user-space.
    >>
    >> Agreed a syscall does the duplication is probably not the way to go.
    >>
    >> A syscall that takes a huge list of objects would solve any security
    >> concerns that we have with returning the object order to user space if
    >> done carefully, but it would require a bunch of additional user space
    >> and kernel memory.
    >>
    >
    > yes, an it increase syscall time itself since we will have to provide
    > this memory dynamically

    I just did a back of the napkin calculation.
    struct kobj_id {
    pid_t pid;
    size_t descriptor;
    size_t first_idx;
    void *kernel_ignore_this_pointer;
    };

    int find_kobject_dups(int type, struct kobj_id __user *ids, size_t count);

    Looks pretty reasonable on a 64bit machine for 100,000 file
    descriptors.

    3 Meg of input data.
    4 Meg of an internal rbtree that remembers the first entry where
    we saw an item.
    struct {
    struct rb_node node;
    void *key;
    size_t idx;
    };

    And the code is very straight forward. Insert each pointer to a kernel
    object we find into an rbtree, and return the index we find. Then
    finally tear down the rbtree.

    8Meg worst case does not seem like a lot of memory to me. Especially
    since half of it is userspace memory.

    A simple implementation plus a guarantee that we will never ever
    leak information that we don't intend to seem very attractive to me.

    >> Sometimes taking a data structure transforming it into a weird form for
    >> a specific task and then transforming the data structure back to it's
    >> original form is a useful way to go. So I think a general kernel object
    >> deduplicating system call is an interesting plan B, but a straight
    >> comparison function if we can make it work is a lot more flexible and
    >> useful.
    >>
    >
    > I hope the root-only restriction would resolve the potential security
    > problem, since as I mentioned if I've hijacked the machine and already
    > goot root -- mem order is not that interesting info I could obtain from
    > such computer :)

    We either need a full comparison operator or we don't. Root-only is a
    solution just looking to get abused.

    Eric


    \
     
     \ /
      Last update: 2012-01-20 04:15    [W:0.038 / U:0.272 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site