Qubes 4.0rc2 allows installation on unsupported hardware.

[Yethal]

Qubes OS version:

4.0rc2

Affected TemplateVMs:

not template related

---

Steps to reproduce the behavior:

1. Launch Qubes 4.0rc2 installation on a PC with no VT-d and SLAT support

Expected behavior:

Prompt appears informing the user that their hardware is unsupported and recommends 3.2 branch.

Actual behavior:

Aforementioned prompt appears but after dismissing it installation proceeds as normal. After the installation finishes dom0 is usable however no VMs can be started (due to lack of VT-d). After setting virt_type to pv AppVMs boot and are 100% usable (excluding other reported issues).

Is it intended for users to be able to install 4.0 on hardware without VT-d? If yes, shouldn't virt_type be changed to pv by default?

General notes:

---

Related issues:

[marmarek]

Generally yes, it was intended to allow installation on not fully supported hardware, but it is meant for power users (understanding implications) and/or developers. So, maybe it is too easily accessible?

@rootkovska @andrewdavidwong what do you think? Currently the warning allow to either abort the installation (default), or continue. The warning text is This hardware lack features required by Qubes OS. Missing features: %(features)s. For more information on supported hardware, please refer to https://www.qubes-os.org/system-requirements/, where %(features)s is replaced with list of:

• HVM/VT-x/AMD-V
• IOMMU/VT-d/AMD-Vi
• HAP/SLAT/EPT/RVI
• Interrupt Remapping

[marmarek]

Generally yes, it was intended to allow installation on not fully supported hardware, but it is meant for power users (understanding implications) and/or developers. So, maybe it is too easily accessible?

@rootkovska @andrewdavidwong what do you think? Currently the warning allow to either abort the installation (default), or continue. The warning text is This hardware lack features required by Qubes OS. Missing features: %(features)s. For more information on supported hardware, please refer to https://www.qubes-os.org/system-requirements/, where %(features)s is replaced with list of:

• HVM/VT-x/AMD-V
• IOMMU/VT-d/AMD-Vi
• HAP/SLAT/EPT/RVI
• Interrupt Remapping

[andrewdavidwong]

I think it would be sufficient to update the warning text as follows:

This hardware lacks features required by Qubes OS. Missing features: %(features)s. Without these features, Qubes OS will not function normally. It is recommended that only developers and power users proceed with the installation. For more information on supported hardware, please refer to https://www.qubes-os.org/system-requirements/

[andrewdavidwong]

I think it would be sufficient to update the warning text as follows:

This hardware lacks features required by Qubes OS. Missing features: %(features)s. Without these features, Qubes OS will not function normally. It is recommended that only developers and power users proceed with the installation. For more information on supported hardware, please refer to https://www.qubes-os.org/system-requirements/

[0spinboson]

What are the implications of my system apparently not supporting interrupt remapping, specifically?

[0spinboson]

What are the implications of my system apparently not supporting interrupt remapping, specifically?

[rootkovska]

What are the implications of my system apparently not supporting interrupt remapping, specifically?

Less resistant to potential (hypothetical) attacks coming from compromised driver domains (e.g. sys-net or sys-usb).

[rootkovska]

What are the implications of my system apparently not supporting interrupt remapping, specifically?

Less resistant to potential (hypothetical) attacks coming from compromised driver domains (e.g. sys-net or sys-usb).

[ag4ve]

Wrt the message s/lack/lacks/

…

On Oct 25, 2017 4:42 AM, "Joanna Rutkowska" ***@***.***> wrote: What are the implications of my system apparently not supporting interrupt remapping, specifically? Less resistant to potential (hypothetical) attacks coming from compromised driver domains (e.g. sys-net or sys-usb). — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#3208 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABNnP7fImWxNONRBCUhBbEVzG3MOOLzUks5svvRxgaJpZM4QFGHd> .

[ag4ve]

Wrt the message s/lack/lacks/

…

On Oct 25, 2017 4:42 AM, "Joanna Rutkowska" ***@***.***> wrote: What are the implications of my system apparently not supporting interrupt remapping, specifically? Less resistant to potential (hypothetical) attacks coming from compromised driver domains (e.g. sys-net or sys-usb). — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#3208 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABNnP7fImWxNONRBCUhBbEVzG3MOOLzUks5svvRxgaJpZM4QFGHd> .

[0spinboson]

any idea why my AMD Ryzen 1600 on a motherboard with a standardized feature set (Asrock ab350 pro4) wouldn't support it?
Afaik AMD has worked pretty closely with virtualization providers (Xen among them) to come up with an interesting and software-supported feature set, so it kind of surprises me to see that this isn't supported. And a quick search does yield, e.g., https://lists.xenproject.org/archives/html/xen-devel/2016-09/msg01815.html , but I'm too unfamiliar with programming to know where to look to triage this.

[0spinboson]

any idea why my AMD Ryzen 1600 on a motherboard with a standardized feature set (Asrock ab350 pro4) wouldn't support it?
Afaik AMD has worked pretty closely with virtualization providers (Xen among them) to come up with an interesting and software-supported feature set, so it kind of surprises me to see that this isn't supported. And a quick search does yield, e.g., https://lists.xenproject.org/archives/html/xen-devel/2016-09/msg01815.html , but I'm too unfamiliar with programming to know where to look to triage this.

[marmarek]

It can be also that our code does not properly detect this feature on AMD. Can you post xl dmesg output?

[marmarek]

It can be also that our code does not properly detect this feature on AMD. Can you post xl dmesg output?

[0spinboson]

dmesg.txt

[0spinboson]

dmesg.txt

[marmarek]

Ok, definitely this case. There is Interrupt remapping enabled, but our code looks for Interrupt Remapping enabled.

[marmarek]

Ok, definitely this case. There is Interrupt remapping enabled, but our code looks for Interrupt Remapping enabled.

[tasket]

I always imagined that someday Qubes would have status indicators or a short report in an "About Qubes" window for these system requirements. You could also have a brief desktop notification at boot time if not all security requirements are met.

[tasket]

I always imagined that someday Qubes would have status indicators or a short report in an "About Qubes" window for these system requirements. You could also have a brief desktop notification at boot time if not all security requirements are met.

[marmarek]

Ok, definitely this case. There is Interrupt remapping enabled, but our code looks for Interrupt Remapping enabled.

The same applies to qubes-hcl-report, as reported here: https://groups.google.com/d/msgid/qubes-users/2a850752-fe00-4887-8632-59d5f774e119%40googlegroups.com

[marmarek]

Ok, definitely this case. There is Interrupt remapping enabled, but our code looks for Interrupt Remapping enabled.

The same applies to qubes-hcl-report, as reported here: https://groups.google.com/d/msgid/qubes-users/2a850752-fe00-4887-8632-59d5f774e119%40googlegroups.com

[qubesos-bot]

Automated announcement from builder-github

The package qubes-core-dom0-4.0.15-1.fc25 has been pushed to the r4.0 testing repository for dom0.
To test this update, please install it with the following command:

sudo qubes-dom0-update --enablerepo=qubes-dom0-current-testing

Changes included in this update

[qubesos-bot]

Automated announcement from builder-github

The package qubes-core-dom0-4.0.15-1.fc25 has been pushed to the r4.0 testing repository for dom0.
To test this update, please install it with the following command:

sudo qubes-dom0-update --enablerepo=qubes-dom0-current-testing

Changes included in this update

[qubesos-bot]

Automated announcement from builder-github

The package pykickstart-2.32-4.fc25 has been pushed to the r4.0 testing repository for dom0.
To test this update, please install it with the following command:

sudo qubes-dom0-update --enablerepo=qubes-dom0-current-testing

Changes included in this update

[qubesos-bot]

Automated announcement from builder-github

The package pykickstart-2.32-4.fc25 has been pushed to the r4.0 testing repository for dom0.
To test this update, please install it with the following command:

sudo qubes-dom0-update --enablerepo=qubes-dom0-current-testing

Changes included in this update

[ReasonablyAnonymous]

Trying to install Qubes 4.0rc3 on new AMD Epyc x360 with Ryzen/Vega chip.
Installation complains about "interrupt remapping" missing hw feature but installs after that.
However, no network adapter works. Probably because the vm's (specifically sys-net) cannot communicate with the adapter hw due to exactly the missing interrupt remapping feature.
Looked up in BIOS - no other settings other than VT hardware enable/disable.
Stuck...

[ReasonablyAnonymous]

Trying to install Qubes 4.0rc3 on new AMD Epyc x360 with Ryzen/Vega chip.
Installation complains about "interrupt remapping" missing hw feature but installs after that.
However, no network adapter works. Probably because the vm's (specifically sys-net) cannot communicate with the adapter hw due to exactly the missing interrupt remapping feature.
Looked up in BIOS - no other settings other than VT hardware enable/disable.
Stuck...

[ReasonablyAnonymous]

Sorry for being slow on the uptake, reading through the posts I find two main topics:

1. Message "unsupported hardware" should be taken seriously, in other words - don't try to install Qubes on this machine as it won't work
2. There is something wrong with the detection (Spelling - Remapping vs. remapping) and it should work once this is fixed as the hardware (AMD Ryzen) is in principle supported and should work

[ReasonablyAnonymous]

Sorry for being slow on the uptake, reading through the posts I find two main topics:

1. Message "unsupported hardware" should be taken seriously, in other words - don't try to install Qubes on this machine as it won't work
2. There is something wrong with the detection (Spelling - Remapping vs. remapping) and it should work once this is fixed as the hardware (AMD Ryzen) is in principle supported and should work

[0spinboson]

I'd look up the NIC hardware to see if you can find out more about it -- interrupt remapping shouldn't be a general issue, and so long as sys-net boots with the thing attached, it probably should work.

[0spinboson]

I'd look up the NIC hardware to see if you can find out more about it -- interrupt remapping shouldn't be a general issue, and so long as sys-net boots with the thing attached, it probably should work.

[ReasonablyAnonymous]

Device which is built into the laptop is the new realtek "8822". Kernel 4.14 onwards supports it. I successfully built it from kernel sources (staging in 4.14) and installed it in Ubuntu 17.10. It's working fine there with the new kernel support.
I tried two other USB devices which both work fine in Ubuntu out of the box.
Those two USB devices show up in dom0 (fresh install Qubes 4.0rc3) as long as I don't use the "USB in specific VM" option during install. Qubes manager then lets me "assign" the devices to a VM, e.g. sys-net, but they are never seen by sys-net. Same for USB flash drives (I tried multiple) or even my cellphone.
Whatever I attach to USB can be seen in lsusb in dom0 but once assigned to a VM it doesn't get seen by that VM.
Booting sys-net (or the entire system) with USB devices attached or not doesn't make any difference, at least not one I can observe.

I can see how lack of interrupt remapping should not be a general issue (there is a post that it's mainly a security benefit to have I.R.) but I can't think of anything else which could cause this?

Having said that - how does the keyboard/mouse communication work with vm's ? At least typing in a VM-shell works fine, one might think that also required interrupts (to be remapped...)?

For now, I'd be fine with dom0 handling USB if only I could find a way to get the proper kernel/drivers installed (requires internet connection) and I could find a way how to make the system utilize dom0 instead of sys-net for that task. I don't know enough Qubes to figure this out without a lot of research...

[ReasonablyAnonymous]

Device which is built into the laptop is the new realtek "8822". Kernel 4.14 onwards supports it. I successfully built it from kernel sources (staging in 4.14) and installed it in Ubuntu 17.10. It's working fine there with the new kernel support.
I tried two other USB devices which both work fine in Ubuntu out of the box.
Those two USB devices show up in dom0 (fresh install Qubes 4.0rc3) as long as I don't use the "USB in specific VM" option during install. Qubes manager then lets me "assign" the devices to a VM, e.g. sys-net, but they are never seen by sys-net. Same for USB flash drives (I tried multiple) or even my cellphone.
Whatever I attach to USB can be seen in lsusb in dom0 but once assigned to a VM it doesn't get seen by that VM.
Booting sys-net (or the entire system) with USB devices attached or not doesn't make any difference, at least not one I can observe.

I can see how lack of interrupt remapping should not be a general issue (there is a post that it's mainly a security benefit to have I.R.) but I can't think of anything else which could cause this?

Having said that - how does the keyboard/mouse communication work with vm's ? At least typing in a VM-shell works fine, one might think that also required interrupts (to be remapped...)?

For now, I'd be fine with dom0 handling USB if only I could find a way to get the proper kernel/drivers installed (requires internet connection) and I could find a way how to make the system utilize dom0 instead of sys-net for that task. I don't know enough Qubes to figure this out without a lot of research...

[0spinboson]

okay. you can build a 4.14-based kernel for qubes using this guide and picking devel-4.14: https://github.com/0spinboson/qubes-doc/blob/patch-1/managing-os/compiling-your-own-kernel.md; build on any pc, move to qubes PC via usb drive.

As for the USBs not showing up, not sure what's going on there. What happens when you attach the usb controller to a VM (using, e.g., 'qvm-pci a sys-net dom0:bla.ba' or 'qvm-pci a sys-net dom0:xy.z -o no-strict-reset=true') before trying to access the usb devices (either in that VM or elsewhere after attaching it)?

As for the IR: it works fine, it's just a parsing issue that leads the tool to misreport its functionality.

[0spinboson]

okay. you can build a 4.14-based kernel for qubes using this guide and picking devel-4.14: https://github.com/0spinboson/qubes-doc/blob/patch-1/managing-os/compiling-your-own-kernel.md; build on any pc, move to qubes PC via usb drive.

As for the USBs not showing up, not sure what's going on there. What happens when you attach the usb controller to a VM (using, e.g., 'qvm-pci a sys-net dom0:bla.ba' or 'qvm-pci a sys-net dom0:xy.z -o no-strict-reset=true') before trying to access the usb devices (either in that VM or elsewhere after attaching it)?

As for the IR: it works fine, it's just a parsing issue that leads the tool to misreport its functionality.

[ReasonablyAnonymous]

Thanks. Great write-up, I'll attempt that in a few days and report back.

[ReasonablyAnonymous]

Thanks. Great write-up, I'll attempt that in a few days and report back.

[qubesos-bot]

Automated announcement from builder-github

The package qubes-core-dom0-4.0.15-1.fc25 has been pushed to the r4.0 stable repository for dom0.
To install this update, please use the standard update command:

sudo qubes-dom0-update

Or update dom0 via Qubes Manager.

Changes included in this update

[qubesos-bot]

Automated announcement from builder-github

The package qubes-core-dom0-4.0.15-1.fc25 has been pushed to the r4.0 stable repository for dom0.
To install this update, please use the standard update command:

sudo qubes-dom0-update

Or update dom0 via Qubes Manager.

Changes included in this update

[qubesos-bot]

Automated announcement from builder-github

The package pykickstart-2.32-4.fc25 has been pushed to the r4.0 stable repository for dom0.
To install this update, please use the standard update command:

sudo qubes-dom0-update

Or update dom0 via Qubes Manager.

Changes included in this update

[qubesos-bot]

Automated announcement from builder-github

The package pykickstart-2.32-4.fc25 has been pushed to the r4.0 stable repository for dom0.
To install this update, please use the standard update command:

sudo qubes-dom0-update

Or update dom0 via Qubes Manager.

Changes included in this update

[ReasonablyAnonymous]

I know technically it has nothing to do with this topic, however, I am rethinking my resolve to move to an OS like Qubes due to the announcement of Meltdown and Spectre, therefore I am not spending much effort right now to make this work by trying the proposed avenue - hence no activity. To be perfectly honest, at least Meltdown is so obvious that I simply don't believe Intel has not known about this exploit and hence necessarily believe that this is a deliberate Trojan making efforts like Qubes basically pointless.This is not a flaw of Qubes or the development teams, I am very grateful for their free efforts. In fact, I am thinking about how I can start contributing more, but it needs to be in a way that "they" (the Intel's that is) are not derailing our efforts to the building of castles in the sand.
Firstly: von Neumann architecture and resulting joint/coherent cache must be eliminated from the base of any "reasonably secure" system. I'll open a separate topic on that.

[ReasonablyAnonymous]

I know technically it has nothing to do with this topic, however, I am rethinking my resolve to move to an OS like Qubes due to the announcement of Meltdown and Spectre, therefore I am not spending much effort right now to make this work by trying the proposed avenue - hence no activity. To be perfectly honest, at least Meltdown is so obvious that I simply don't believe Intel has not known about this exploit and hence necessarily believe that this is a deliberate Trojan making efforts like Qubes basically pointless.This is not a flaw of Qubes or the development teams, I am very grateful for their free efforts. In fact, I am thinking about how I can start contributing more, but it needs to be in a way that "they" (the Intel's that is) are not derailing our efforts to the building of castles in the sand.
Firstly: von Neumann architecture and resulting joint/coherent cache must be eliminated from the base of any "reasonably secure" system. I'll open a separate topic on that.

[0spinboson]

In a case of what must be cosmic coincidence, Intel appears to have started working on a replacement for the choices that allowed for Meltdown to be a thing in June 2016 at the latest: https://software.intel.com/sites/default/files/managed/4d/2a/control-flow-enforcement-technology-preview.pdf
That aside, this will most likely lead to delays as hardware is redesigned.

[0spinboson]

In a case of what must be cosmic coincidence, Intel appears to have started working on a replacement for the choices that allowed for Meltdown to be a thing in June 2016 at the latest: https://software.intel.com/sites/default/files/managed/4d/2a/control-flow-enforcement-technology-preview.pdf
That aside, this will most likely lead to delays as hardware is redesigned.

[ReasonablyAnonymous]

Posted as new issue #3448

[ReasonablyAnonymous]

Posted as new issue #3448