What prevents use of a storage driver domain?

[Adin Kapul]

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?

Kind Regards,

ileyd

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

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.

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

iQEcBAEBCAAGBQJX8hfxAAoJENuP0xzK19cs4BsH/RmG7u21gSVHvxDLr7ugyuB0
i6fNQkj+bYymjX+76pFAHmiIhVYMR5V1AYZjNSZ0O4T7dXVGpvmIjrgZ3vK00SNA
tHEvQ2N4SvY8uo7BPQMjvtjM+crVQTaMVa8mKKzzBWLSj2DxBI1c5PtwC8Y12dgQ
7FimTWbgEIZhiOshwoJU2euwZUKVpXXgA5VLSTubY5WuqK1tiE8WyxhLizq5iigy
0PE9FNPV5t6oG6K8MrqloSt2PdZybrsH6vqvOQ20k2Gnf4MHBSzSkH2T9lVNCNKF
TnGiNaUUAvr2jqGIrWOO2ADed8NqKumq/RS1JjoTDzLa2n0T2ft3rNgR+oa3BWM=
=rDhQ
-----END PGP SIGNATURE-----

[ileyd]

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?

--

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 qubes-devel...@googlegroups.com.

To post to this group, send email to qubes...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/20161003083353.GC7105%40mail-itl.

For more options, visit https://groups.google.com/d/optout.

Hi,

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.

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.

What do you mean by your comment on the problems with ME and TXT?

Warm Regards,
ileyd

[ileyd]

To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/EA0E81F5-DDB4-4937-8876-A3264BF8248B%40icloud.com.

For more options, visit https://groups.google.com/d/optout.

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

[Marek Marczykowski-Górecki]

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

[ileyd]

--
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 qubes-devel...@googlegroups.com.
To post to this group, send email to qubes...@googlegroups.com.

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.

Hi,

> 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.

That is true.  Though if the encryption domain is separated from the disk controller one, I still don't see why trusted boot is necessary, for there to be any benefit (making disk controller drivers untrusted; their compromise unable to lead to full system compromise) to this.    See below for what I mean by this, with dm-crypt running in a separate domain to that which has direct access to disks:

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.

Does the depiction above satisfy that?  In such a scenario, the domain with direct access to the disks, running the disk controller drivers, etc, would not be in a position to modify (authenticated encryption may be necessary to ensure this) nor read the contents.  Obviously though this raises questions as to how to handle key storage for the dm-crypt domain, perhaps making use of sealed secrets in the TPM.

> 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

Does this mean that the position taken by the Qubes project towards Intel ME and TXT, is that they are completely useless and there is not much point to making use of them?  If so, what benefits are afforded by AEM, and is it planned to be deprecated?  If not, considering it is the only form of trusted boot available an commodity hardware at the moment, would it not satisfy the requirements of trusted boot for a storage domain?

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.

I would imagine the initramfs would be stored on the normal /boot partition, with its integrity verified/enforced through Intel TXT (sealed secrets), and optionally UEFI Secure Boot (which some implementations of have been shown to have vulnerabilities allowing it to be bypassed, I am aware), though storing it on an external device like is suggested with AEM would limit the opportunity for the contents to be modified.  See above for comment on threat of initramfs compromise without working trusted boot.  With system and disk controller firmware backdooring, assuming signed firmware updating, surely a limited degree of implicit trust must be placed in the firmware vendors, considering these are threats that still presently apply to Qubes and potentially result in full system compromise?

I guess your central point here, is that the introduction of a storage domain would be a non-negligible development effort, and the perceived benefits of such are minimal if any.  The main benefit I see to this, is that it allows for the storage controller drivers to be removed from dom0, and so their compromise would no longer lead to a full system compromise, but a denial of service attack at worst.  This keeps with the aim of dom0 disaggregation, and removes an avenue for system compromise (this would leave only the audio, graphics, and input drivers in dom0, wouldn't it?).  A potential other benefit, though unlikely at the moment, would be that if dom0 were not permitted full control (this would likely require use of XSM policy as well; potentially see OpenXT for reference) over the encryption domain, it would allow for dom0 to never have access to key material, requiring a separate compromise of that domain to exfiltrate them.

Warm Regards.

ileyd