linux-kernel - Re: [RFC] Unify KVM kernel-space and user-space code into a single project

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]

Message-ID: <20100322140205.GB14201@elte.hu>
Date:	Mon, 22 Mar 2010 15:02:05 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	"Richard W.M. Jones" <rjones@...hat.com>
Cc:	"Daniel P. Berrange" <berrange@...hat.com>,
	Pekka Enberg <penberg@...helsinki.fi>,
	Avi Kivity <avi@...hat.com>,
	Antoine Martin <antoine@...afix.co.uk>,
	Olivier Galibert <galibert@...ox.com>,
	Anthony Liguori <anthony@...emonkey.ws>,
	"Zhang, Yanmin" <yanmin_zhang@...ux.intel.com>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Sheng Yang <sheng@...ux.intel.com>,
	linux-kernel@...r.kernel.org, kvm@...r.kernel.org,
	Marcelo Tosatti <mtosatti@...hat.com>,
	oerg Roedel <joro@...tes.org>,
	Jes Sorensen <Jes.Sorensen@...hat.com>,
	Gleb Natapov <gleb@...hat.com>,
	Zachary Amsden <zamsden@...hat.com>, ziteng.huang@...el.com,
	Arnaldo Carvalho de Melo <acme@...hat.com>,
	Fr?d?ric Weisbecker <fweisbec@...il.com>
Subject: Re: [RFC] Unify KVM kernel-space and user-space code into a single
 project


* Richard W.M. Jones <rjones@...hat.com> wrote:

> On Mon, Mar 22, 2010 at 01:05:13PM +0000, Daniel P. Berrange wrote:
> > This is close to the way libguestfs already works. It boots QEMU/KVM pointing
> > to a minimal stripped down appliance linux OS image, containing a small agent
> > it talks to over some form of vmchannel/serial/virtio-serial device. Thus the
> > kernel in the appliance it runs is the only thing that needs to know about the
> > filesystem/lvm/dm on-disk formats - libguestfs definitely does not want to be
> > duplicating this detailed knowledge of on disk format itself. It is doing
> > full read-write access to the guest filesystem in offline mode - one of the
> > major use cases is disaster recovery from a unbootable guest OS image.
> 
> As Dan said, the 'daemon' part is separate and could be run as a standard 
> part of a guest install, talking over vmchannel to the host. The only real 
> issue I can see is adding access control to the daemon (currently it doesn't 
> need it and doesn't do any).  Doing it this way you'd be leveraging the 
> ~250,000 lines of existing libguestfs code, bindings in multiple languages, 
> tools etc.

I think it would be a nice option to allow such guest-side "daemon's" to be 
executed in the guest context without _any_ guest-side support.

This would be possible by building such minimal daemons that use vmchannel, 
and which are built for generic x86 (maybe even built for 32-bit x86 so that 
they can run on any x86 distro). They could execute as the init task of any 
guest kernel - Qemu could 'blend in / replace' the binary as the init task of 
the guest temporarily - and some simple bootstrap code could then start the 
daemon and start the real init binary (and turn off the 'blending' of the init 
task).

That way any guest could be extended via such Qemu functionality - even 
without any kernel changes. Has anyone thought about (or coded) such a 
solution perhaps?

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