Message-ID: <m1ty3rukr1.fsf@fess.ebiederm.org>
Date:	Thu, 19 Jan 2012 19:16:02 -0800
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Cyrill Gorcunov <gorcunov@...il.com>
Cc:	david@...g.hm, "H. Peter Anvin" <hpa@...or.com>,
	Alexey Dobriyan <adobriyan@...il.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Pavel Emelyanov <xemul@...allels.com>,
	Andrey Vagin <avagin@...nvz.org>, Ingo Molnar <mingo@...e.hu>,
	Thomas Gleixner <tglx@...utronix.de>,
	Glauber Costa <glommer@...allels.com>,
	Andi Kleen <andi@...stfloor.org>, Tejun Heo <tj@...nel.org>,
	Matt Helsley <matthltc@...ibm.com>,
	Pekka Enberg <penberg@...nel.org>,
	Eric Dumazet <eric.dumazet@...il.com>,
	Vasiliy Kulikov <segoon@...nwall.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Valdis.Kletnieks@...edu
Subject: Re: [RFC] syscalls, x86: Add __NR_kcmp syscall

Cyrill Gorcunov <gorcunov@...il.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
--
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/

Powered by blists - more mailing lists