On Thu, Aug 20, 2009 at 04:38:17PM +0300, Michael S. Tsirkin wrote: > On Thu, Aug 20, 2009 at 03:10:54PM +0200, Arnd Bergmann wrote: > > On Thursday 20 August 2009, Michael S. Tsirkin wrote: > > > On Wed, Aug 19, 2009 at 05:27:07PM +0200, Arnd Bergmann wrote: > > > > On Wednesday 19 August 2009, Michael S. Tsirkin wrote: > > > > > On Wed, Aug 19, 2009 at 03:46:44PM +0200, Arnd Bergmann wrote: > > > > > > On Wednesday 19 August 2009, Michael S. Tsirkin wrote: > > > > > > > > > > > > Leaving that aside for now, you could replace VHOST_NET_SET_SOCKET, > > > > > > VHOST_SET_OWNER, VHOST_RESET_OWNER > > > > > > > > > > SET/RESET OWNER is still needed: otherwise if you share a descriptor > > > > > with another process, it can corrupt your memory. > > > > > > > > How? The point of using user threads is that you only ever access the > > > > address space of the thread that called the ioctl. > > > > > > Think about this example with processes A and B sharing an fd: > > > A does SET_USED_ADDRESS > > > B does SET_USED_ADDRESS > > > A does VHOST_NET_SPLICE > > > See how stuff gets written into a random place in memory of A? > > > > Yes, I didn't think of that. It doesn't seem like a big problem > > though, because it's a clear misuse of the API (I guess your > > current code returns an error for one of the SET_USED_ADDRESS > > ioctls), so I would see it as a classic garbage-in garbage-out > > case. > > > > It may even work in the case that the sharing of the fd resulted > > from a fork, where the address contains the same buffer in both > > processes. I can't think of a reason why you would want to use > > it like that though. > > It doesn't matter that I don't want this: allowing 1 process corrupt > another's memory is a security issue. Once you get an fd, you want to > be able to use it without worrying that a bug in another process will > crash yours. > If B's SET_USED_ADDRESS fails how one process can corrupt a memory of other process? -- Gleb. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
