One problem is that when you dual or multiboot, even if you are using encryption on your Qubes installation, /boot is still unprotected and could be maliciously modified by the other OS, possibly leading to Qubes itself being maliciously modified.
The other problem is firmware security - for example the other system could infect the BIOS firmware, which might enable compromise or spying on the Qubes system.
Might be worth drawing a line between “security support” and “technical support” here - multiboot may be very valuable for developer use cases (where all operating systems on the system are trusted equally). Such a setup may be discouraged from a security standpoint, but essential for development. I for instance run a multiboot setup on my test laptop, Kubuntu/Lubuntu/Qubes OS/Debian/Arch.
Qubes OS doesn’t support multiboot, but in practice it can be multibooted pretty easily.
Also, how would this interact with portable installations? They have some of the same risks, but may be very valuable because they can provide enhanced security even when a user has to use a machine that runs less secure operating systems other times.
This aligns with the OS/hardware relation, as I have pointed out (in “Operating System from Heaven”) the insecurity of having a separation between OS and hardware. There is another threat, which is having multiboot, as it poses stability and security issues.
So it’s like a path of a consistent, homogeneous methodology for security.
We should not have a single concern about what xyz wants to have on his laptop. Our concern is to deliver the best security possible for the end user while he’s using our OS/products. If something doesn’t work unless you allow insecurities, it is unsupported.
The user is going to need to play with those on bare metal VM or emulator. Or buy insecure, testing purpose hardware (secure OS/hardware doesn’t support this).
Security support: None required related specifically to dual/multi boot.
Security impact: Almost entirely the same discussion as No Rescue Mode.
Overhead from dual-boot / multi-boot technical/documentation/forum support requests: Non-existing at this point. I could not find any questions at this time on the topic of dual-boot / multi-boot support requests. If this were to happen minimal to no time would be spend on these requests as this is notoriously difficult to debug. This would most likely be redirected as per Potential Solutions Beyond Kicksecure! and Self Support First Policy for Kicksecure.
Developer use cases: These remain “supported” (as in “possible”) (as in developers can figure it out) without “support” from the project required. When Kicksecure is installed on standard Intel/AMD64 hardware, this feature is a by-product. There is nothing useful from a security point of view that we can do to stop “supporting” (meaning, this being possible) that feature.
In general I understand this sentiment, but in practice these kinds of capabilities are needed to develop Kicksecure itself. It’s difficult to say “XYZ should not be supported on Kicksecure” when Kicksecure depends somewhat on XYZ to exist.
Neither is an option for many Kicksecure development workflows because the developer must test specifically how the OS behaves on specific physical hardware platforms. Virtualization isn’t useful here. For example, emerg-shutdown, which is intended to be a component of Kicksecure 18, was triggering a bug that caused physical hardware with an Intel GPU to panic rather than shutting down when the emergency condition was triggered. This didn’t occur in a VM because the VM did not have an Intel GPU. Being able to discover and fix this bug is a vital part of why emerg-shutdown will actually be usable once development is finished.
Allowing “X system” to be booted alongside Kicksecure aids Kicksecure
development because a surprising amount of the time, “X system” provides an
environment for developing some component for an OS that cannot be easily
developed or tested on that OS. Examples:
Kloak version 2, intended for Kicksecure 18, could not be developed on
Kicksecure 17 as the needed Wayland compositor (labwc) was not present in
Debian 12’s repos. I had to install Debian 13 in a multiboot scenario to
develop and test it properly, and physical hardware was needed to get
touchpad support working
Xen kernel command line support in GRUB, intended for Qubes OS R4.3 (or
maybe R4.4 at this point), could not be developed on Qubes OS R4.3 because
contributing the feature to upstream GRUB was necessary, requiring the
compilation of both Xen and GRUB from upstream sources on a very up-to-date
distribution. I had to install Arch Linux in a multiboot scenario to
develop and test this feature properly, and physical hardware was needed to
properly test virtualization-related functions.
Now in both situations you could argue I should just get another computer
in that instance, or swap hard drives. But that requires purchasing
additional drives and/or computers, and while a world where all developers
have infinite resources, that would be great, but that isn’t the world most
open-source devs live in. It’s within my means to buy another computer or
NVMe drive, but I’d rather not.
It costs us nothing to not go out of our way to break multiboot. It saves
me and others time and money. If we really are worried about multiboot, we
could pop up a warning, but that’s the most I’d be comfortable with.