From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753364AbXCaTuu (ORCPT ); Sat, 31 Mar 2007 15:50:50 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753376AbXCaTuu (ORCPT ); Sat, 31 Mar 2007 15:50:50 -0400 Received: from x35.xmailserver.org ([64.71.152.41]:48156 "EHLO x35.xmailserver.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753364AbXCaTut (ORCPT ); Sat, 31 Mar 2007 15:50:49 -0400 X-AuthUser: davidel@xmailserver.org Date: Sat, 31 Mar 2007 12:50:48 -0700 (PDT) From: Davide Libenzi X-X-Sender: davide@alien.or.mcafeemobile.com To: Andrew Morton cc: Linux Kernel Mailing List , Linus Torvalds , Ingo Molnar , Suparna Bhattacharya , Zach Brown , Benjamin LaHaise Subject: Re: [patch 10/13] signal/timer/event fds v8 - eventfd core ... In-Reply-To: <20070330182603.5d6817d3.akpm@linux-foundation.org> Message-ID: References: <20070330124028.c6e54d2e.akpm@linux-foundation.org> <20070330182603.5d6817d3.akpm@linux-foundation.org> X-GPG-FINGRPRINT: CFAE 5BEE FD36 F65E E640 56FE 0974 BF23 270F 474E X-GPG-PUBLIC_KEY: http://www.xmailserver.org/davidel.asc MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 30 Mar 2007, Andrew Morton wrote: > On Fri, 30 Mar 2007 18:11:55 -0700 (PDT) Davide Libenzi wrote: > > > > > > > + */ > > > > > > So it is the caller's responsibility to ensure that *file refers to an > > > eventfd file? > > > > In which function? I lost you ... > > > > eventfd_signal() assumes that the passed in file* refers to an eventfd > file. So if a caller passes in a file* for /etc/passwd, the kernel will go > splat. > > I guess that's caveat emptor, and any violations of that will show up > quickly in testing. My main concern would be that there might be some way > for a naughty user to force the kernel to pass a non-eventfd file* into > this function. That depends upon as-yet-unwritten code - is there a risk > of this happening, and how do we prevent it? That's the kernel side of the API. The userspace->kernel fd validation is done in eventfd_fget(), that the kernel uses to get an eventfd file* from an eventfd file descriptor. The eventfd_fget() does the file operations check and returns proper error. At that point, if the kernel feeds eventfd_signal() with crap, it gets crap back. Like calling internal kernel functions with bogus mm_struct or task_struct. > > > > + DECLARE_WAITQUEUE(wait, current); > > > > + > > > > + if (count < sizeof(ucnt)) > > > > + return -EINVAL; > > > > + if (get_user(ucnt, (const __u64 __user *) buf)) > > > > + return -EFAULT; > > > > > > Some architectures do not implement 64-bit get_user() > > > > copy_from_user it is, then ... > > > > spose so. I think architectures _should_ implement 64-bit get_user() and > put_user() nowadays. So you could leave the code as-is and inform the arch > maintainers, if you're feeling keen. > > If all this code has its own Kconfig options then the architectures won't > break until their maintainers come along to enable the new features, so > they'll implement 64-bit get_user() at that time and things will all unfold > in a nicely non-chaotic fashion. Agreed. I'll leave the get_user(u64). - Davide