-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On Tue, Oct 04, 2016 at 06:36:19PM +1000, ileyd wrote: > > > On 4 Oct. 2016, at 3:48 pm, ileyd <[email protected]> wrote: > > > > > > > >> From: ileyd <[email protected]> > >> Date: 4 October 2016 at 3:43:45 pm AEST > >> To: Marek Marczykowski-Górecki <[email protected]> > >> Subject: Re: [qubes-devel] What prevents use of a storage driver domain? > >> > >> > >>> On 3 Oct. 2016, at 6:33 pm, Marek Marczykowski-Górecki > >>> <[email protected]> wrote: > >>> > >>> -----BEGIN PGP SIGNED MESSAGE----- > >>> Hash: SHA256 > >>> > >>>> On Sun, Oct 02, 2016 at 01:25:19AM +0000, Adin Kapul wrote: > >>>> Hi, > >>>> > >>>> > >>>> > >>>> I am curious what prevents (even if not completely untrusted) > >>>> implementation of a storage driver domain. > >>>> > >>>> > >>>> It is discussed in the architecture document, and has been alluded to by > >>>> Joanna, so I'd assume that this is an eventual aim of the Qubes project. > >>>> > >>>> > >>>> > >>>> The process is relatively simple on stock Xen, and Qubes already > >>>> supports using AppVMs as storage driver domains to serve locally-stored > >>>> images (just as Dom0 stores guest images) to other guests, so I'm > >>>> curious what obstacles there are to implementing this for the main guest > >>>> storage, or is it simply a case of it not being a priority and no one > >>>> having worked on it? > >>> > >>> Moving all the storage to separate domain means that dom0 have no direct > >>> access to hard drive. This makes boot process much more complex - for > >>> example dom0 also needs to be booted somehow - to start that storage > >>> domain. This, to be meaningful in any way, require working trusted boot. > >>> And given problems with Intel ME and TXT implementation, there is no > >>> hardware providing it. > > > > Could you elaborate on what you said? > > > > Would the boot process really be made very much more complex? The storage > > domain root needs to be stored separately so that it may be accessed at > > boot time, and the storage domain would need to be started by the > > initramfs. Neither of these would be particularly challenging, would they? > > Dom0's storage would still appear as normal block devices to it, so it > > shouldn't affect the boot process after that. There is no need for a fully > > booted dom0; all the necessary bootstrapping could easily occur in a dom0 > > initramfs.
But you need things like boot configuration (what should be started as storage domain, apply updates etc), key management (as explained in architecture). Also fitting everything needed to start a domain in initramfs will make that initramfs much larger (which can be a problem in some cases[1]). And some components (like xenstored) cannot be restarted, so you'll be left with processes still running with initramfs as rootfs, even after switching to normal root (or you'll need to implement switch root in such components). This all is of course doable, but complex. So, we think it worth going that way only if it's meaningful increase of system security. > > Could you additionally elaborate on why full trusted boot is an absolute > > necessity for this to be meaningful at all? I am aware of course that > > without a separate encryption VM, this domain would be in a very trusted > > position, able to modify all root file systems. Exactly. Including boot images (xen, dom0 kernel, initramfs etc) (*). This means compromised storage domain is basically full system compromise. So there will be no gain from separating it, besides making things more complex. Just to clarify - properly done storage domain would separate two things out of TCB: - disk backend drivers (xen-blkback), exposing disks to VMs - storage subsystem (SATA controller, firmware, drivers) Any of those can compromise storage domain, so it makes sense only when compromised storage domain can not break into other components. > > What do you mean by your comment on the problems with ME and TXT? For example this list: http://invisiblethingslab.com/itl/Resources.html Or article linked here: http://blog.invisiblethings.org/2015/10/27/x86_harmful.html > To clarify, how I imagine this working: > > • dom0 initramfs contains minimal xen toolstack > • storage domain initramfs available as file in dom0 initramfs > > Dom0 initramfs boots as normal up until where it would usually switch to new > root > Dom 0 starts storage domain using the initramfs available > Storage domain boots as normal having full access to all disks, mounts root > from disk > Dom0 mounts root from storage domain > Dom0 switches to new root and boots as normal Something like this (but see my earlier comment). (*) You could say - lets keep them on separate device, connected only at boot time. Yes, this will improve some things, but will not solve all the problems. For example such system would be still vulnerable to backdoored SATA controller firmware (which can subvert boot process using DMA, even when booting from other devices). Or malicious BIOS (either backdoored by vendor, or reflashed later). And you still need to connect this device sometimes, to apply updates, modify configuration etc. At this time, whatever you use to sandbox this subsystem (USB VM, storage domain etc), it can compromise that device, which - without working trusted boot - may be left unnoticed. [1] https://github.com/QubesOS/qubes-issues/issues/794#issuecomment-135988806 - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJX83pKAAoJENuP0xzK19csLmIIAIpj//wMlnthHkplY+L/MM+H m++9FjO5ahVWeQS50+0DEQRhrJws8koRdz0BvK716SooDYsJLzgpKnJrVxUmTx6+ 7N31p4j3FHnxYhy5YQ8/QFjLUo+SBjlf4Q7tQUgs54FWGgYfXin68/0b0WVMJGTx +B95PFcnt7PA+v1MqTUHL7kiS6ssaEgXxJVUwZTY2gaLYnh3BUWQ48Z7IzOPB+l+ m3m322GEpRIRm5+OibXu/+5S7JJWE6iuv2sf3gJ1rGcjX6/emSf/NXrIFNfjufKW vrOXdE2G1oJUmtPzlUjubny+IyJIyfoYQm5D+6xVUvBqgUIrgvevuTeEryKVWa4= =6lsD -----END PGP SIGNATURE----- -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/20161004094546.GL2436%40mail-itl. For more options, visit https://groups.google.com/d/optout.
