On Fri, 30 Mar 2007, Andrew Morton wrote: > On Fri, 30 Mar 2007 18:11:55 -0700 (PDT) Davide Libenzi > <davidel@xmailserver.org> 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
