From qubes-devel Sat Nov 05 08:46:05 2016 From: Joanna Rutkowska Date: Sat, 05 Nov 2016 08:46:05 +0000 To: qubes-devel Subject: [qubes-devel] Re: Running (or not) Xen during installation Message-Id: <20161105084604.GC16325 () work-mutt> X-MARC-Message: https://marc.info/?l=qubes-devel&m=147833557312122 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On Thu, Nov 03, 2016 at 09:13:26PM +0100, Marek Marczykowski wrote: > Hi, > > Currently Qubes OS installer is starting full Xen + Linux dom0 to > perform installation. On one hand it is good, because it is obvious at > this early stage if hardware is not compatible (especially display > driver and its cooperation with Xen). But on another hand, it is IMHO > much easier to fix such problems having the system already installed. > When even installer does not start, in most cases the only alternative > is trying other installer (in extreme case - building custom > installation image). Also, starting Xen for installation require some > effort when preparing the installer (see below). > > Initially running Xen was needed because all qubes tools crashed when > running without it - for example most of the tools do check running VM > list and of course there is no such thing when running without Xen. > But since Qubes OS 3.0, it is no longer the case - we have introduced so > called "offline mode" to perform those few tasks (create initial > qubes.xml, register installed template(s) etc) without need to launch > libvirt daemon in chroot environment there. All the tasks really > requiring Xen running are performed during first boot. > > Long story short - technically Xen is no longer needed during > installation of Qubes OS. Or at least is very close to such state. > > So, now the question - do we want to keep launching Xen for > installation, or launch just plain Linux? > > Benefits of keeping Xen: > - earlier (negative) confirmation of hardware compatibility > - possibility of (re-)introducing later something that require Xen running > during installation > - rescue mode have Xen running (but not libvirt), which may ease some > tasks > - no need to change anything related to ISO build, at least not right > now > > Benefits of dropping Xen: > - no longer limited to 32MB of initrd for UEFI boot[1] > - easier starting installation in non standard environment (network > boot, non standard installation media) > - ability to use almost any tool to write USB installation image (most > of them, like unetbootin, generously setup a bootloader to launch > _linux_ image found in the ISO image) > - better changes to install on not perfectly compatible hardware and > easier way to adjust the system afterwards (like - get at least > command line access and upgrade the kernel) > - less work when upgrading to new installer version (as part of > upgrading dom0 distribution) > > [1] > https://github.com/QubesOS/qubes-issues/issues/794#issuecomment-135988806 > > PS I'm writing this exactly because of the ticket linked above - I hit > this problem again when building some Qubes OS 4.0 test images... > In the long term, we would like to maintain *full* isolation of most of the PCIe devices (so DMA and MSI capable) from the TCB (perhaps except for the MCH pseudo devs). This should be maintained throughout the whole boot process, starting from the reset vector. I don't think running Linux would allow us to achieve that. So, we should aim at keeping Xen, and in the future, when we have better firmware to work with (Coreboot?) make sure that at no point in time any of the untrusted PCIe, such as your WiFi NIC, can interfere with the boot process. joanna. -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJYHZxMAAoJEDOT2L8N3GcYXSwP/1adPL/1OCEV1BVsnBiNvTsf gNdYZcND3sWdT7185d9W/seUvQiW5QHcr9tJd0uoI/2WSNMeDVU6oyLRW2AdcUZu IDgyjhqq1EFRorVqyIcXg23Xv25wcM5KqsxqZqLseGyUIB7+zlJMFK9meBYsD2VJ XTRl0CnevBkX6cdDUWejz7iDj4X2PUehe+onkAK0ptBfudqsiw9WGhEDQB5A/BJC LK3weIeVckZ6tgfqzljWA3c7MwFb6NY8j+A28gU2oSWssKauIeny9vTtsD2p+63h MSzvBQSQWO+mfeXnB4ZfDPARnZ54+A3mWGY3pb3sT55+e8jR5LKao29pDoAqRrod M911vht2PSWoQwWxTZ9QdRrX9ykBju+yHbgqRSFIyVl/1kdW5vS84xUP7t790sMO 4DvaoyOYYoz+hHPKmCdX5JFZDaLQKPI5l9aYcZdkrVxtFg4GMPvEg1AE/JMP+pm/ mcbZqDXhNbkgEbhVMDpM6LnKTkbHITgL1Jr6OUuIErqj57nAsGe99woRtUmrZfzU z6/ZNwQFjgyFg4IC3dRqPK0Mrd4pbI3Cs8VPNO9dGQBObCE6WeUgRU78Wh/Xj0pU Cqcrvz7EsgdCvi2E3x2DCjPsBzmm4WG3K+Xt7fmivBY+dzornwzN9iHABIBxkRjV AvLXdvygO4jKP/etHBfX =E7HD -----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 qubes-devel+unsubscribe@googlegroups.com. To post to this group, send email to qubes-devel@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/20161105084604.GC16325%40work-mutt. For more options, visit https://groups.google.com/d/optout.