linux-kernel - Re: [RFC/GIT PULL] Linux KVM tool for v3.2

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] [day] [month] [year] [list]

Message-ID: <CAJSP0QWRBE6VLskVb0rYaVO3bEB6=8=F6GsNBjQAvn68X2aD2Q@mail.gmail.com>
Date:	Thu, 10 Nov 2011 15:33:04 +0000
From:	Stefan Hajnoczi <stefanha@...il.com>
To:	Markus Armbruster <armbru@...hat.com>
Cc:	Pekka Enberg <penberg@...nel.org>,
	Anthony Liguori <anthony@...emonkey.ws>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Avi Kivity <avi@...hat.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Ingo Molnar <mingo@...e.hu>, linux-kernel@...r.kernel.org,
	kvm@...r.kernel.org, Christoph Hellwig <hch@....de>
Subject: Re: [RFC/GIT PULL] Linux KVM tool for v3.2

On Thu, Nov 10, 2011 at 2:47 PM, Markus Armbruster <armbru@...hat.com> wrote:
> Pekka Enberg <penberg@...nel.org> writes:
>
>> Hi Anthony,
>>
>> On Thu, Nov 10, 2011 at 3:43 PM, Anthony Liguori <anthony@...emonkey.ws> wrote:
>>> It's not just the qcow2 implementation or even the block layer.  This pull
>>> requests adds a userspace TCP/IP stack to the kernel and yet netdev isn't on
>>> the CC and there are no Ack's from anyone from the networking stack.  I'm
>>> fairly sure if they knew what was happening here they would object.
>>
>> It's something we consider extremely important because it allows easy
>> non-root networking. But you're right, we definitely ought to ping the
>> networking folks before the next merge window.
>
> The problem is real.  The solution "duplicate in user space" sucks.  If
> you engaging with the kernel networking folks leads to one that doesn't
> suck, we should bathe you in free beer.

Look at disks, the problem is addressed by the udisks daemon on dbus.
Anything can try talking to it.  If you have permissions or can get
the user to authenticate then you can manipulate LVM volumes, mount
file systems, etc.  We could do something similar for tap networking.

The Ubuntu folks seem to want VDE instead to solve the same problem.
Create a VDE switch with a single tap device on startup.  Then let all
VMs talk to the VDE without privileges.

I don't think going through VDE is nice or performant, would be better
to have add virtual network functionality over dbus just like udisks
did for disks.

Stefan
--
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/