linux-kernel - Re: [PATCH 3/3] eventfd: add internal reference counting to fix notifier race conditions

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 25 Jun 2009 21:12:24 +0930
From:	Rusty Russell <rusty@...tcorp.com.au>
To:	Davide Libenzi <davidel@...ilserver.org>
Cc:	Gregory Haskins <ghaskins@...ell.com>, mst@...hat.com,
	kvm@...r.kernel.org,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	avi@...hat.com, paulmck@...ux.vnet.ibm.com,
	Ingo Molnar <mingo@...e.hu>
Subject: Re: [PATCH 3/3] eventfd: add internal reference counting to fix notifier race conditions

On Thu, 25 Jun 2009 08:15:11 am Davide Libenzi wrote:
> On Wed, 24 Jun 2009, Rusty Russell wrote:
> > On Tue, 23 Jun 2009 03:33:22 am Davide Libenzi wrote:
> > > What you're doing there, is setting up a kernel-to-kernel (since
> > > userspace only role is to create the eventfd) communication, using a
> > > file* as accessory. That IMO is plain wrong.
> >
> > The most sensible is that userspace can use these fds; an in-kernel
> > variant is possible too, but not primary IMHO.
> >
> > It's nice that userspace create the fds; it can then use the same fd for
> > multiple event sources.
> >
> > But I didn't see anything wrong with the way eventfd used to work: you
> > have a kvm ioctl to say "attach this eventfd to this guest notification"
> > and that does the eventfd_fget.  A detach ioctl does the fput (as does
> > release of the kvm fd).
> >
> > If they close the eventfd and don't do the detach ioctl, it's their
> > problem.
>
> Some components would like to know if userspace dropped the fd, and take
> proper action accordingly (release resources, drop module instances,
> etc...).

Like to know?  Possibly.  Need to know?  Not anything I've seen so far.

If userspace creates the fd, component grab a ref and if userspace wants that 
fd completely freed must close the fd *and* tell component.  Simple, race free 
and explicit.  All wins.

As this discussion shows, doing some kind of implies non-reference is hard, 
complex and racy.

> Another thing that comes in my mind (that for some components might not
> matter) is considering the effect of userspace doing things like:
>
> 	for (;;) {
> 		fd = eventfd(...);
> 		ioctl(xfd, XXX_ADD, fd);
> 		close(fd);
> 	}
>
> That might lead to unprivileged users drawing kernel memory w/out any
> userspace accountability, if not properly handled.

No, fget_eventfd covers this exactly as expected.  Don't doubt your ability to 
design sane kernel interfaces; eventfd is nice!  All lguest needed was a 
couple of EXPORT_SYMBOLS and it fitted in beautifully.

Thanks,
Rusty.
--
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/