> 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. >>> >>> - -- >>> 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----- >>> >>> -- >>> 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/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 > -- > 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/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 -- 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/013C39E8-399C-45D4-A073-6BCD33D6C1A5%40icloud.com. For more options, visit https://groups.google.com/d/optout.
