linux-kernel - Re: [Xen-devel] Re: [GIT PULL] Xen APIC hooks (with io_apic

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: <4A1DDF8B.6020000@goop.org>
Date:	Wed, 27 May 2009 17:49:15 -0700
From:	Jeremy Fitzhardinge <jeremy@...p.org>
To:	Ingo Molnar <mingo@...e.hu>
CC:	Dan Magenheimer <dan.magenheimer@...cle.com>,
	Avi Kivity <avi@...hat.com>,
	George Dunlap <George.Dunlap@...citrix.com>,
	Xen-devel <xen-devel@...ts.xensource.com>,
	the arch/x86 maintainers <x86@...nel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Keir Fraser <keir.fraser@...citrix.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [Xen-devel] Re: [GIT PULL] Xen APIC hooks (with io_apic_ops)

Ingo Molnar wrote:
> I also find it pretty telling that you cut out the most important 
> point of Avi's reply:
>
>   
>>> I think the Xen design has merit if it can truly make dom0 a 
>>> guest -- that is, if it can survive dom0 failure.  Until then, 
>>> you're just taking a large interdependent codebase and splitting 
>>> it at some random point, but you don't get any stability or 
>>> security in return.
>>>       
>
> that crucial question really has to be answered honestly and 
> upfront.

Xen, the hypervisor itself, doesn't require any services from dom0. From 
its perspective, dom0 is just another guest domain, though with enough 
privileges to access hardware.  Dom0's job is to provide device access 
to other less privileged domains.

There is currently some system-wide information which is stored in a 
usermode daemon in dom0. Recovering from its loss is hard, but there is 
a prototype to pull that daemon out into its own special-purpose 
domain.  At that point, dom0 can reboot without affecting any of the 
other domains or Xen itself.

If dom0 goes away, the other domains will get a disconnect and 
temporarily lose access to their devices, but they can cope with that.  
 From their perspective, it would look like they'd just been 
save/restored or migrated to another machine.  When dom0 comes back, 
they'll reconnect and carry on.

The disaggregation of dom0's functions is something that the Xen 
development community is actively perusing.

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