[prev in list] [next in list] [prev in thread] [next in thread] 

List:       qubes-devel
Subject:    [qubes-devel] Re: Running (or not) Xen during installation
From:       Joanna Rutkowska <joanna () invisiblethingslab ! com>
Date:       2016-11-05 8:46:05
Message-ID: 20161105084604.GC16325 () work-mutt
[Download RAW message or body]

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


[prev in list] [next in list] [prev in thread] [next in thread]