Running (or not) Xen during installation

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

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

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

iQEcBAEBCAAGBQJYG5ppAAoJENuP0xzK19cs7BsH/R8tfHYryBeopo4BF/zOFTIu
btxtDSWNA17YQ3RuIUrdKCMZPZft0+7mgSw+MgLctY3yz/lhuOp3NgTR8r00MTBU
fvjfS/KRaBZj4agPoxYe1+BRAOeBduLQi5G8NLhMl1H8w3Omjjy8kqyhxmc0uNR/
yEGvSCNJJyGgpKCjZOkXggP5HUWBXVDNfOkxBh6maTFPOuPCNiWVdd+iDrXZuvKX
g4r1GbZNfVeEZIsieyjNQBNiZLTpqab53Kk+nMUG88yRcD8RpQ50sY4grjnXJlW9
TLpx9GIUeQBPUAo5pJl/28VZvfHtliqXI4+cF1kL9uZH587eac3hPKeRbz8pDlk=
=ESsV
-----END PGP SIGNATURE-----

[Andrew David Wong]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 2016-11-03 13:13, Marek Marczykowski-Górecki wrote:
> So, now the question - do we want to keep launching Xen for
> installation, or launch just plain Linux?
>

By far one of the most common problems new users encounter (as reported on
Twitter, Reddit, and qubes-users) is getting a blank screen with a blinking
cursor when they initially try to install Qubes. I'm guessing this is Xen
failing to launch due to less than perfect hardware compatibility (in some
cases, probably outright incompatibility). If you think avoiding this would
be valuable, then that's one thing in favor of dropping Xen during
installation.

- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJYG5ztAAoJENtN07w5UDAwaacQAKGxieqqQXrwyFp+jRXW25YR
q63da+lzM++zXqnCtBFWr3fNNxK9mluvgtYm86Kbl9I4nNV5+09P6GzVGh9Xc0HJ
PnEHXKbbBo+Vyflt6SSyH1fIqS4APGBhBRflZYlnptkalFi6f2D/Fol6Ad81CgxP
cBSdNDCSjrbY3EBb10wlqBE+J34a409m437M//r2MNtrb9PicEZ4KKy/HHcDv9H1
fCJu0o0e05Iqi78FECgu/V27ova2lP4ZAMXAsBFkApi+HIBDPZG4jiUbFvHGUTnn
CsqGAY8+s8LLl0VJSb8K1Wzwrdp43+BrA/Ev0cgJ3EONAl+ZeaveieaM/AMcTAjc
ZStiMcxCUhwkO0GMC0oz3EPgWlhhr4ANdUIEe0JJlnJqnnnD+Nerci0LWY4RA4yI
ruvbtp2WuQabB9me9iMTC3F9UZjJLzbCfeI1tW6TcF172UNuE4yqdt8GW4Q9teNs
7Nvc9R/8U44HmDauN+BBRo31VzrJzUzLMopKHUB82tPOG+yH98Be4o0C8Za3U/hK
BiUCNW1vATWsV90js6nlW1SVv5/h6Mj40Y/XjyRX3K6xHHkzwW5VhgoJMh4KJbFm
z5EPvuKvXq3O57CE6jnQDnPvV9QQb4doeBDevydKnTGl4yeiLORWRtVINwVPB/0H
9pJ+eQ7q5FvdmoWx1lwB
=XEis
-----END PGP SIGNATURE-----

[Trammell Hudson]

On Thu, Nov 03, 2016 at 09:13:26PM +0100, Marek Marczykowski-Górecki wrote:
> [...]

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

One other option is to use a minimal Linux image that can then kexec
Xen/dom0/initrd without any of the UEFI limitations. This also addresses
the various interesting alternate installation techniques -- if Linux
has a driver for the NIC/filesystem/etc it is possible to use it to
fetch, verify and invoke the next stages.

--
Trammell

[Trammell Hudson]

On Thu, Nov 03, 2016 at 02:26:28PM -0600, Trammell Hudson wrote:
> One other option is to use a minimal Linux image that can then kexec
> Xen/dom0/initrd without any of the UEFI limitations. This also addresses
> the various interesting alternate installation techniques -- if Linux
> has a driver for the NIC/filesystem/etc it is possible to use it to
> fetch, verify and invoke the next stages.

Additionally, as axon pointed out:

> By far one of the most common problems new users encounter (as reported on
> Twitter, Reddit, and qubes-users) is getting a blank screen with a blinking
> cursor when they initially try to install Qubes.

Using a normal Linux kernel before jumping into Xen would allow
testing of the hardware prior to kexec'ing the hypervisor.

--
trammell

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Thu, Nov 03, 2016 at 02:26:28PM -0600, Trammell Hudson wrote:

That's indeed interesting and in fact I was trying something like this
when initially fighting with this UEFI problem. But every attempt to
kexec Xen from Linux failed. How to do that? And how to pass dom0 kernel
+ initrd there? Will dom0 kernel started that way have access to UEFI
runtime services - which is needed to setup bootloader parameters?

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

iQEcBAEBCAAGBQJYG58hAAoJENuP0xzK19csdSgH/irZEXWlxa5199N3sy4+nkAp
gNCRTGlIs2WPpan1lcRGjZH5QdxFsbCWNM5GOrq5uBP4OWuaI/Si4cSmtOTOAmfO
VbkDp80qeaWk+KWKDpDi2e9uqPeGaVvdk8aAWzjD5zlRGjtwfkgP0uGnX+MiTQoY
j6OiLC8Y1dSvO2BiuzYsFmqI2XnBjt2N0o83ZwH5Fq8FFOC6JwbpsDb3h1UH+xFy
9YivzOFmISIiSlXgd88I9xNtCGa1b967jxmfK+yIeKewJE67tKGSc/WK2q5puXMc
oMxNxHLAMObhBqda+Y4byjZ47g50xWU1aV5nWYgJ8Vq8ZuPlOhn7iVmAuVGLKY4=
=R6uV
-----END PGP SIGNATURE-----

[7v5w7go9ub0o]

On 11/03/2016 08:24 PM, Andrew David Wong wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> On 2016-11-03 13:13, Marek Marczykowski-Górecki wrote:
>> So, now the question - do we want to keep launching Xen for
>> installation, or launch just plain Linux?
>>
> By far one of the most common problems new users encounter (as reported on
> Twitter, Reddit, and qubes-users) is getting a blank screen with a blinking
> cursor when they initially try to install Qubes. I'm guessing this is Xen
> failing to launch due to less than perfect hardware compatibility (in some
> cases, probably outright incompatibility). If you think avoiding this would
> be valuable, then that's one thing in favor of dropping Xen during
> installation.
>
> - --
> Andrew David Wong (Axon)
>

+1; please drop it.

[Trammell Hudson]

On Thu, Nov 03, 2016 at 09:33:34PM +0100, Marek Marczykowski-Górecki wrote:
> On Thu, Nov 03, 2016 at 02:26:28PM -0600, Trammell Hudson wrote:
> > One other option is to use a minimal Linux image that can then kexec

> > Xen/dom0/initrd without any of the UEFI limitations. [...]

>
> That's indeed interesting and in fact I was trying something like this
> when initially fighting with this UEFI problem. But every attempt to
> kexec Xen from Linux failed. How to do that?

I posted patches to the Xen list that remove dependencies on legacy BIOS
things like EBDA, although I don't think they have been (nor will they
be?) merged. kexec of Xen was broken between Xen 3.1.0 and 3.1.3 almost a
decade ago and apparently no one else was sufficiently impacted by the
change to track it down:

https://lists.xen.org/archives/html/xen-devel/2016-08/msg01195.html

If there is an actual BIOS the VGA patches might not be necessary;
all of my test machines thus far are using coreboot with no legacy
support, so I haven't explored the minimal patch set to Xen.

> And how to pass dom0 kernel + initrd there?

kexec of a multboot kernel (like xen) allows multiple modules including
the kernel (and parameters) and the initrd. You can see my Qubes
start script (run from Linux-as-bootloader in ROM) here:

https://github.com/osresearch/heads/blob/master/initrd/start-xen

> Will dom0 kernel started that way have access to UEFI
> runtime services - which is needed to setup bootloader parameters?

I'm not sure about that. Again, none of my test machines have any
legacy firmware nor any traditional bootloaders, so I haven't explored
how it interacts with those pieces.

--
Trammell

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Thu, Nov 03, 2016 at 02:51:38PM -0600, Trammell Hudson wrote:
> On Thu, Nov 03, 2016 at 09:33:34PM +0100, Marek Marczykowski-Górecki wrote:
> > On Thu, Nov 03, 2016 at 02:26:28PM -0600, Trammell Hudson wrote:
> > > One other option is to use a minimal Linux image that can then kexec
> > > Xen/dom0/initrd without any of the UEFI limitations. [...]
> >
> > That's indeed interesting and in fact I was trying something like this
> > when initially fighting with this UEFI problem. But every attempt to
> > kexec Xen from Linux failed. How to do that?
>
> I posted patches to the Xen list that remove dependencies on legacy BIOS
> things like EBDA, although I don't think they have been (nor will they
> be?) merged. kexec of Xen was broken between Xen 3.1.0 and 3.1.3 almost a
> decade ago and apparently no one else was sufficiently impacted by the
> change to track it down:
>
> https://lists.xen.org/archives/html/xen-devel/2016-08/msg01195.html
>
> If there is an actual BIOS the VGA patches might not be necessary;
> all of my test machines thus far are using coreboot with no legacy
> support, so I haven't explored the minimal patch set to Xen.
>

> > Will dom0 kernel started that way have access to UEFI
> > runtime services - which is needed to setup bootloader parameters?
>
> I'm not sure about that. Again, none of my test machines have any
> legacy firmware nor any traditional bootloaders, so I haven't explored
> how it interacts with those pieces.

Ok, this (and that Xen don't care about kexec) means we don't want to do
this. The reason for dropping Xen from installer is to make it easier to
maintain, closer to commonly used configuration. Using kexec from Linux
payload of Coreboot may be really cool, but not for large variety of
hardware.

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

iQEcBAEBCAAGBQJYHACoAAoJENuP0xzK19csilIH/1XudM68yPDAHQP2H6/wAD1G
3VueJdMn2h77AyA/mKNx0ug0lTMnUH/ssZZIEODKevzHr5+z0jeViMOakIIKvpyl
EfpJKJEQHWy5sbC7dffI+gwliGcRpSeJbgxdse1+t42Cc/uEkUouD8kxs9H3NGda
iV8xnmoSGCTGbzsLJqsclBM6plLATgXSSPQzh1RyF6t37SXVxvhScOTsigG6TnHZ
dfjQ0w4OvYg4FKBK2KSe4yul/ShSaL4KmTocf6Qr3AdsX5iMEPXl3RzG/qyqaRb8
aYUKunZ2IjoRUKsbrz0CmFGFbW5Jg9VLDy6+59imre8gES7DKickoYWeUVf6cZU=
=Z5q6
-----END PGP SIGNATURE-----

[Trammell Hudson]

On Fri, Nov 04, 2016 at 04:29:41AM +0100, Marek Marczykowski-Górecki wrote:
> [...] Ok, this (and that Xen don't care about kexec) means we don't want to
> do this.

I'm worried that they didn't follow up on the report from 2008.
It does make me question how many users kexec into new kernels.

> [...] Using kexec from Linux

> payload of Coreboot may be really cool, but not for large variety of
> hardware.

There is nothing special about the Linux kernel or kexec binary
I'm using. Those are both stock; the two line Xen patch skip the
EBDA probe is the only custom code. Perhaps if it were wrapped up
to be part of the 'no-real-mode' command line option they would merge it
(although the probe happens prior to command line parsing right now).

--
Trammell

[Zrubi]

On 11/03/2016 09:13 PM, Marek Marczykowski-Górecki wrote:
>
> 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?

I would say we should drop Xen.

However in this case we may have to include a basic hardware
compatibility check module to the installer.


--
Zrubi

[Holger Levsen]

Hi,

On Thu, Nov 03, 2016 at 09:13:26PM +0100, Marek Marczykowski-Górecki wrote:

> Long story short - technically Xen is no longer needed during
> installation of Qubes OS. Or at least is very close to such state.

given the benefits you described, I think it makes sense not to use Xen
during installation _as long as_ there is a live image one can use
to test ones hardware with Xen/Qubes.


--
cheers,
Holger

[Ivan]

Seconded - there should really be a way to test hardware compatibility
before installing. The live image could be a smallish qubes install with
test reports during boot as the "full" usb live image may be useless if
users can't access the test report because they're stuck at a blank screen.

Ivan

[Matteo]

I think that an option to check compatible hardware is useful,
and as far as i know since the installer starts xen this is a good way
to check if Qubes OS is compatible (not perfect because here installer
starts good but stops when creating net-vm because of wifi driver problem)
for example, if i buy new pc i will:
-get model info at the shop (and mostly online)
-ask someone at the shop "can i plug this usb key and boot?"
-->checked if Qubes is compatible

what about removing xen (which seems that makes many tasks easier)
and add a boot option "check compatibility" which starts xen and
display: "hello from xen: it works; vt-x present; vt-d missing; tpm
missing;"
forgive me if what i'm asking is no-sense and if this is too much
off-topic, i'm new to mailing lists

[Andrew David Wong]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 2016-11-04 10:01, Matteo wrote:
> I think that an option to check compatible hardware is useful,
> and as far as i know since the installer starts xen this is a good way
> to check if Qubes OS is compatible (not perfect because here installer
> starts good but stops when creating net-vm because of wifi driver problem)
> for example, if i buy new pc i will:
> -get model info at the shop (and mostly online)
> -ask someone at the shop "can i plug this usb key and boot?"
> -->checked if Qubes is compatible
>
> what about removing xen (which seems that makes many tasks easier)
> and add a boot option "check compatibility" which starts xen and
> display: "hello from xen: it works; vt-x present; vt-d missing; tpm
> missing;"

Isn't this the point of installing Qubes on a portable USB drive so that
you can plug it in to other machines to test it (e.g., qubes-hcl-report)?

> forgive me if what i'm asking is no-sense and if this is too much
> off-topic, i'm new to mailing lists
>

Not off-topic, but please try to avoid top-posting. Since you say you're
new to mailing lists, you may wish to take a look at our mailing list
guidelines:

https://www.qubes-os.org/mailing-lists/

- --
Andrew David Wong (Axon)

Community Manager, Qubes OS
https://www.qubes-os.org
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJYHUB5AAoJENtN07w5UDAwhI0P/2WnfNo+p/on+MOH5zuosEnE
Y+IZSQzO5IZENoBYjDeUZgLlY9L9/96+OK0shz5hsxIRL456M3w4KyEFJ3cSFGSM
pPPPFEsCsgBUjcmTSCvs0v45smkDE2lsL13qVPGawaQebLCg8tcBaMmFWxd1SakM
okdvwo3qBb0OSHGcbrkyLjBOzlod/lxm8XUdEYciHEUwrldfKTGm7LbMJyaPdcwr
gqbsKpP3Qql163SsP7MzVN5gbT+MS+GfoXwbn+hZnSrFvil5r0/IsDWL/fO+Lhg4
mPLznirS83J9pr8cIBEAZY0Jvy3DTu5ZNWpLxU02C5V9YzNysxq5R1gNiLNxx74m
EjPu7aSjy308R/OmDQC3TM4rF3sfWXuJWrnLYR2ttE1bQDATdVztla/T2+MIy/va
aok9PMFO9kExObA6v5v5FJr9UQcEFenQF9FDgvGr7Hr3hDLz5TOVOWI5Nn0nLce9
PFOBaONycAYUW215vUgH+TZTpuyP334CGBFuttR4FmFEIeF97KcP1ohZioyUOR9p
h98lnVD9j7lhPtaE+uzZeWCEiHN8ZVEG9jxJ1E5UnboUBpQ842K7lLnX0rW+oxpP
kinLAE282OgDq6Q8j1R/q18vp6kBJghgaADc2oHDK0NsPJqhcuq459kZZdVEvtav
EyB3Pt4wswe6JcbD6QfG
=6WFP
-----END PGP SIGNATURE-----

[Manuel Amador (Rudd-O)]

On 11/03/2016 08:13 PM, Marek Marczykowski-Górecki wrote:
> Hi,
> [...]

> So, now the question - do we want to keep launching Xen for
> installation, or launch just plain Linux?

You're asking us about something whose answer you already know.

And we agree with you.

If there is no security benefit from launching the installer under Xen,
then kill Xen in the installer.

Just make a note during the install that the first boot may fail, and
provide a prominent link to a page where users can go AFTER the install
is done, to diagnose why their system does not boot.

That last part is really important!

--
Rudd-O
http://rudd-o.com/

[Manuel Amador (Rudd-O)]

On 11/04/2016 12:07 PM, Ivan wrote:
>
>
> Seconded - there should really be a way to test hardware compatibility
> before installing.

A menu entry right under "Test and install the image" during the
installer GRUB boot?

That would be very nice, actually. Donno what the menu entry should do,
but it should probably try to boot into Xen, then into Linux, then run a
/sbin/init that is a Hello World program, which accepts any key to reboot.

(We'll sell those Any Key USB peripherals to make ourselves REAL RICH!)

--
Rudd-O
http://rudd-o.com/

[Joanna Rutkowska]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

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

[Chris Laprise]

On 11/05/2016 04:46 AM, Joanna Rutkowska wrote:
>
> 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.

Speaking of long-term, it would be interesting to know if ITL could
consider specifying a hardware platform where Qubes or a Qubes-like OS
could operate with greater consistency. The Qubes community currently
spends most of its time and effort trying to reconcile the OS with the
whims and priorities of Windows PC vendors.

Even if its not realistic to build such a PC in the near term, having a
hardware (and firmware) specification that supports the objectives of
Qubes could be educational and garner interest from more
hardware-focused people and projects. It would also serve as a reminder
of how (comparatively) problematic most PCs are.

Chris

[Andrew David Wong]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

What you're describing sounds like the required specifications for Qubes-certified hardware beginning with R4.0:

https://www.qubes-os.org/news/2016/07/21/new-hw-certification-for-q4/

Or did you have something different in mind?

- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJYH/LTAAoJENtN07w5UDAw2K0QAJwJthLjxrqLew+3wTDZWgTZ
aqOgbuhzK7jLf1ORr5f12B3iy0dn8LdOcZ+168DJMlcGiJrWr6gJglFLV+STWytu
rQw0eZgbdN+srnSIf0RnshOGHowo4NLwUp02IgYyWAQ9WY2K4IbYFP+UKgX98QaT
Euhg1e3Dynjd8N1T9zeLk1034wpp8hq5rSIuKEfuq1MwN550e6CH0btUF/okR/VS
76k+TtkaZUAzfPzlKFwS61/LdA/OeP0k44xvKJKPOiNY7Jpwt+a6o9Wl59K1rrLg
7kWpn3VVmMz0v5JvailsSJ5Bie8Ijl+GQQQMA/YdTTMQqUYXGuNiIzHPNIIpzWUx
M8fMDMY0PLFDkoh2G92YhGNpsMzkRC+yOivpR8QtDGyVdYf3Pc89HdlWVrVj9wJz
imViTTiZZlod8cz3PjkhzJeOxond+2X4QJQi5h8L03KKDZf+ThB2Oy5mlKaJ1ZRx
LhxN0cmz+bM1dhuuomg/NnH/vQu31k9eGZfIrblqdXoNNU/OofqQGBqoqFGKEjp2
PodXEdatXdPmnowUrOvExONvN6OKyukOxjXcywGgimOdiX2C7Wsowl14cIMy0xJb
5LEjFCCSI2lw3etp3AFRFKKu5/CxC5SmIvqxDv7ZStV0fzWpqghUfHw403gf4IyE
hV9tdYQB0AHMygkRmtgd
=3oMw
-----END PGP SIGNATURE-----

[Chris Laprise]

On 11/06/2016 10:19 PM, Andrew David Wong wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> On 2016-11-06 15:14, Chris Laprise wrote:
>> On 11/05/2016 04:46 AM, Joanna Rutkowska wrote:
>>> 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.
>> Speaking of long-term, it would be interesting to know if ITL could consider specifying a hardware platform where Qubes or a Qubes-like OS could operate with greater consistency. The Qubes community currently spends most of its time and effort trying to reconcile the OS with the whims and priorities of Windows PC vendors.
>>
>> Even if its not realistic to build such a PC in the near term, having a hardware (and firmware) specification that supports the objectives of Qubes could be educational and garner interest from more hardware-focused people and projects. It would also serve as a reminder of how (comparatively) problematic most PCs are.
>>
>> Chris
>>
> What you're describing sounds like the required specifications for Qubes-certified hardware beginning with R4.0:
>
> https://www.qubes-os.org/news/2016/07/21/new-hw-certification-for-q4/
>
> Or did you have something different in mind?
>
> - --
> Andrew David Wong (Axon)
> Community Manager, Qubes OS
> https://www.qubes-os.org

Something else entirely... Like specifying CPU features, instruction
sets, bus characteristics, etc. using currently available open hardware
designs as a starting point. I think Joanna would be able to do or at
least oversee much of this planning. It would have a high-level aspect
stating the minimal hardware features at a macro level, but more
importantly it would drill way down to the hardware logic and would
serve as a guide for specific implementation plans used to fabricate
chips and motherboards.

So, ultimately, systems built for non-x86 Qubes could be planned openly
down to the last logic gate.

There would also have to be an establishment of procedures to serve as a
"reasonable" guide for auditing manufacturing processes (e.g. help
ensure chip fabrication delivers product without surprises).

An opportunity exists here to introduce a truly proper replacement for
"regular PCs", which I think are a poor match for the kind of security
Qubes is trying to deliver. Currently its like taking an old hotel
building and trying to turn it into a rocket gantry.

Chris