On 11/09/2009 09:35 PM, Jamie Lokier wrote:
What I'd like to know is, if all of QEMU's state is appropriately
recreated in the child instance, and KVM's device is reopened with a
copy of the kvm state (by using the recently introduced ioctls to get
and set it), will it fork the _guest RAM_
Avi Kivity wrote:
On 11/09/2009 09:35 PM, Jamie Lokier wrote:
What I'd like to know is, if all of QEMU's state is appropriately
recreated in the child instance, and KVM's device is reopened with a
copy of the kvm state (by using the recently introduced ioctls to get
and set it), will it
Avi Kivity wrote:
On 11/07/2009 12:44 PM, Jamie Lokier wrote:
Aiee - what's the plan? Can a running KVM be forked, as in into two
separate processes to run the forked guests in parallel, or not?
kvm fds do not support fork(). Nothing prevents you from stopping the
guest, reading guest
On 11/08/2009 12:12 AM, Anthony Liguori wrote:
Arnd Bergmann wrote:
Well, the difference matters from a security perspective. The sudo
script that Avi suggested just means that you can guarantee you don't
introduce any security holes through a suid executable. Fortunately,
it does not impact
On Fri, Nov 06, 2009 at 08:26:29PM +, Jamie Lokier wrote:
But imho it'd be far nicer not to have specialness like that unless
you want it for some positive reason like security.
OTOH, if you do want this for security, there's currently no
way to do this besides using raw sockets + macvlan.
On 11/06/2009 04:19 PM, Anthony Liguori wrote:
Avi Kivity wrote:
Instead of doing silly things into qemu, if there is concern about
this, then it should be fixed in Linux properly.
Of course there is concern about it, and you don't have to do
anything silly to qemu to avoid it. Just not
On 11/06/2009 06:09 PM, Anthony Liguori wrote:
No, it's an argument against fork() of large programs.
After putting together a work around, I'm starting to have my doubts
about how real of a problem this is.
You're only write protecting memory, correct?
The kernel write protects qemu
On 11/07/2009 11:14 AM, Avi Kivity wrote:
I'd welcome -net bridge as one of them. But we shouldn't try to
invent access control systems or install suid helpers.
We can make the helper a script that does
exec sudo /the/real/helper $@
so a user can add it to /etc/sudoers and get
Avi Kivity wrote:
So vfork() is required, or in light of its man page and glowing
recommendations from the security people,
vfork() on Linux is fine to use, as long as you respect it's unwritten
requirements :-)
In a multithreaded program: you can start by spawning a thread for the
sole
On 11/07/2009 12:44 PM, Jamie Lokier wrote:
Aiee - what's the plan? Can a running KVM be forked, as in into two
separate processes to run the forked guests in parallel, or not?
kvm fds do not support fork(). Nothing prevents you from stopping the
guest, reading guest state, fork()ing,
Avi Kivity wrote:
Running qemu directly from the command line is absolutely an
important use case.
Where does this requirement come from?
For most of qemu's lifetime, this was the only option. The current
graphical front ends only support a subset of qemu's features and qemu's
target
Avi Kivity wrote:
On 11/07/2009 11:14 AM, Avi Kivity wrote:
I'd welcome -net bridge as one of them. But we shouldn't try to
invent access control systems or install suid helpers.
We can make the helper a script that does
exec sudo /the/real/helper $@
so a user can add it to /etc/sudoers
On Saturday 07 November 2009, Anthony Liguori wrote:
Avi Kivity wrote:
On 11/07/2009 11:14 AM, Avi Kivity wrote:
I'd welcome -net bridge as one of them. But we shouldn't try to
invent access control systems or install suid helpers.
We can make the helper a script that does
exec
Arnd Bergmann wrote:
Well, the difference matters from a security perspective. The sudo
script that Avi suggested just means that you can guarantee you don't
introduce any security holes through a suid executable. Fortunately,
it does not impact the contents of your helper either, only the
Avi Kivity wrote:
Helpers are really bad. On launch, I find the fragile and hard to do
proper error handling with (but that's probably just me). But the
real problem is at runtime, if you have a 16GB guest then you have to
write-protect 4M ptes and then kvm has to tear down or write protect
Avi Kivity wrote:
On 11/05/2009 07:20 PM, Arnd Bergmann wrote:
On Thursday 05 November 2009, Anthony Liguori wrote:
It'd still install the default helper you've provided and use it by
default, of course.
That's already how it behaves. You can say -net
Anthony Liguori wrote:
Avi Kivity wrote:
Helpers are really bad. On launch, I find the fragile and hard to do
proper error handling with (but that's probably just me). But the
real problem is at runtime, if you have a 16GB guest then you have to
write-protect 4M ptes and then kvm has to
Daniel P. Berrange wrote:
On Thu, Nov 05, 2009 at 04:41:45PM +, Jamie Lokier wrote:
Anthony Liguori wrote:
Absolutely. I wanted to not have a hard dependency on PolicyKit to
start out with but that's always been the plan. I'd like to eventually
add an optional PolicyKit
Michael S. Tsirkin wrote:
On Thu, Nov 05, 2009 at 04:12:36AM +, Jamie Lokier wrote:
I notice that if we eventually teach the kernel to have unnamed
bridges (just attach interfaces to each other), only the helper
commands will need changing to use it :-)
What do you mean by attach
Daniel P. Berrange wrote:
On Thu, Nov 05, 2009 at 11:03:48AM -0600, Anthony Liguori wrote:
Daniel P. Berrange wrote:
Indeed the hotplug scenario is a bit of a problem in this model,
since libvirt needs to be able to setup iptables ebtables rules
between creating the device giving it to
Avi Kivity wrote:
On 11/05/2009 05:59 PM, Anthony Liguori wrote:
Avi Kivity wrote:
On 11/05/2009 05:11 PM, Daniel P. Berrange wrote:
The main problem is that we've never really used the 'session'
instances,
since networking configs are rather limited to pretty much just SLIRP
and people
Avi Kivity wrote:
On 11/05/2009 07:16 PM, Scott Tsai wrote:
On Fri, Nov 6, 2009 at 12:50 AM, Anthony Liguorialigu...@us.ibm.com
wrote:
It's just a bit annoying to create an entire new
project for a few hundred line helper.
This new project would also be a better place for
Avi Kivity wrote:
On 11/05/2009 06:50 PM, Anthony Liguori wrote:
I'm worrying that we're transforming one problem into two different
ones. Expanding the scope of qemu, and making it more difficult to
use advanced networking functionality.
Do you object to the idea of having qemu call
Avi Kivity wrote:
I don't see why you consider placing functionality in the
management stack vs qemu user hostile, considering who our users are.
Do you mean that virtually all users use a management stack?
-- Jamie
On 11/05/2009 09:58 PM, Anthony Liguori wrote:
Avi Kivity wrote:
Helpers are really bad. On launch, I find the fragile and hard to do
proper error handling with (but that's probably just me). But the
real problem is at runtime, if you have a 16GB guest then you have to
write-protect 4M ptes
On 11/06/2009 02:29 AM, Anthony Liguori wrote:
Helpers are really bad. On launch, I find the fragile and hard to do
proper error handling with (but that's probably just me). But the
real problem is at runtime, if you have a 16GB guest then you have to
write-protect 4M ptes and then kvm has
On 04.11.2009, at 01:28, Anthony Liguori wrote:
This series solves a problem that I've been struggling with for a
few years now.
One of the best things about qemu is that it's possible to run
guests as an
unprivileged user to improve security. However, if you want to have
your guests
Alexander Graf wrote:
Yeah. Worse than the run as root part is the it's hard part
though. I hate how I feel when I try to explain someone how to use
non-slirp networking :-(.
The response to that is then usually oh whatever, it's too
complicated anyways.
I agree and it's a problem I would
Anthony Liguori wrote:
Alexander Graf wrote:
Yeah. Worse than the run as root part is the it's hard part
though. I hate how I feel when I try to explain someone how to use
non-slirp networking :-(.
The response to that is then usually oh whatever, it's too
complicated anyways.
I agree and
This series solves a problem that I've been struggling with for a few years now.
One of the best things about qemu is that it's possible to run guests as an
unprivileged user to improve security. However, if you want to have your guests
communicate with the outside world, you're pretty much
30 matches
Mail list logo
