-----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 <
il...@icloud.com> wrote:
> >
> >
> >
> >> From: ileyd <
il...@icloud.com>
> >> Date: 4 October 2016 at 3:43:45 pm AEST
> >> To: Marek Marczykowski-Górecki <
marm...@invisiblethingslab.com>
> >> Subject: Re: [qubes-devel] What prevents use of a storage driver domain?
> >>
> >>
> >>> On 3 Oct. 2016, at 6:33 pm, Marek Marczykowski-Górecki <
marm...@invisiblethingslab.com> 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-----