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