RT @kylerankin: There's a reason @QubesOS marks the network VM as untrusted. Safer to treat your network that way #KRACK or not.
A Brief Introduction to the Xen Project and Virtualization from Mohsen Mostafa Jokar
https://blog.xenproject.org/2017/10/17/a-brief-introduction-to-the-xen-project-and-virtualization-from-mohsen-mostafa-jokar/
Mohsen Mostafa Jokar is a Linux administrator who works at the newspaper Hamshahri as a network and virtualization administrator. His interest in virtualization goes back to when he was at school and saw a Microsoft Virtual PC for the first time. He installed it on a PC with 256 MB of RAM and used it […]
https://blog.xenproject.org/2017/10/17/a-brief-introduction-to-the-xen-project-and-virtualization-from-mohsen-mostafa-jokar/
Mohsen Mostafa Jokar is a Linux administrator who works at the newspaper Hamshahri as a network and virtualization administrator. His interest in virtualization goes back to when he was at school and saw a Microsoft Virtual PC for the first time. He installed it on a PC with 256 MB of RAM and used it […]
MSI support for PCI device pass-through with stub domains
https://www.qubes-os.org/news/2017/10/18/msi-support/
Introduction
In this post, we will describe how we fixed MSI support for VMs running in HVM mode in Qubes 4.0.
First, allow us to provide some background about the MSI feature and why we need it in the first place.
In Qubes 4.0, we switched from paravirtualized (PV) virtual machines to hardware virtual machines (HVMs, also known as “fully virtualized” or “hardware-assisted” VMs) for improved security (see the 4.0-rc1 announcement (https://www.qubes-os.org/news/2017/07/31/qubes-40-rc1/#fully-virtualized-vms-for-better-isolation) for details).
For VMs running as HVMs, Xen requires software that can emulate hardware (such as network cards) called QEMU in order to provide device emulation.
By default, Xen runs QEMU in the most trusted domain, dom0, and QEMU has quite a large attack surface.
Running QEMU in dom0 would jeopardize the security of Qubes, so it is necessary to run QEMU outside of dom0.
We do this by using a Xen feature that allows us to run QEMU inside a second “helper” VM called a “stub domain”.*
This way, an attacker who exploits a bug in QEMU will be confined to the stub domain rather than getting full access to dom0.
Admittedly, stub domains run in PV mode, which means that an attacker who were to successfully exploit QEMU would gain the ability to exploit potential Xen bugs in paravirtualization.
Nonetheless, we believe using HVMs to host PCI devices is still a considerable improvement.
Of course, in the long term, we would like to switch to using PVH VMs, but at the moment this is not feasible.
In our testing, we found that pass-through PCI devices did not work in HVMs on some machines.
On the affected machines, networking devices and USB devices, for example, were not usable as they are in Qubes 3.2.
(The kernel driver failed to initialize the device.)
This was a major problem that would have blocked us from moving entirely from PV to HVM in Qubes 4.0.
For this reason, the Qubes 4.0-rc1 installer configures all VMs that have attached PCI devices to use PV mode so that those PCI devices will function correctly.
Problems
After much further testing, we discovered that the affected PCI devices don’t work without MSI support.
(MSI is a method to trigger an interrupt from a PCI device.)
The devices we observed to be problematic were all newer Intel devices (integrated USB controllers and a Wi-Fi card).
While the PCIe standard allows for devices that don’t support legacy interrupts, all the affected devices advertised support for legacy interrupts.
But no interrupts were ever delivered after the driver configured the device.
This made the bug tricky to track down, since we were looking for an error on the software side.
To get those devices working, we needed MSI support.
When running QEMU in dom0, MSI support (and therefore the problematic devices) worked, but with stub domains, it was broken.
This is why, until now, we’ve had patches in place to hide MSI capability from the guest so that the driver doesn’t try to use it (one patch for the Mini-OS-based stub domain (https://github.com/QubesOS/qubes-vmm-xen/blob/ff5eaaa777e9d6ba42242479d1cabacfbdc728ca/patches.misc/hvmpt02-disable-msi-caps.patch) and another for the new Linux-based stub domain (https://github.com/QubesOS/qubes-vmm-xen-stubdom-linux/blob/71a01b41a9cf69d580c652a7147c0a8eb33ced97/qemu/patches/disable-msi-caps.patch)).
We found two issues that were preventing MSI support from working with stub domains.
First, the stub domain did not have the required permission on the IRQ, which is reserved for the MSI in the map_pirq hypercall QEMU makes.
(The IRQ is basically a number to distinguish between interrupts from different devices.)
https://www.qubes-os.org/news/2017/10/18/msi-support/
Introduction
In this post, we will describe how we fixed MSI support for VMs running in HVM mode in Qubes 4.0.
First, allow us to provide some background about the MSI feature and why we need it in the first place.
In Qubes 4.0, we switched from paravirtualized (PV) virtual machines to hardware virtual machines (HVMs, also known as “fully virtualized” or “hardware-assisted” VMs) for improved security (see the 4.0-rc1 announcement (https://www.qubes-os.org/news/2017/07/31/qubes-40-rc1/#fully-virtualized-vms-for-better-isolation) for details).
For VMs running as HVMs, Xen requires software that can emulate hardware (such as network cards) called QEMU in order to provide device emulation.
By default, Xen runs QEMU in the most trusted domain, dom0, and QEMU has quite a large attack surface.
Running QEMU in dom0 would jeopardize the security of Qubes, so it is necessary to run QEMU outside of dom0.
We do this by using a Xen feature that allows us to run QEMU inside a second “helper” VM called a “stub domain”.*
This way, an attacker who exploits a bug in QEMU will be confined to the stub domain rather than getting full access to dom0.
Admittedly, stub domains run in PV mode, which means that an attacker who were to successfully exploit QEMU would gain the ability to exploit potential Xen bugs in paravirtualization.
Nonetheless, we believe using HVMs to host PCI devices is still a considerable improvement.
Of course, in the long term, we would like to switch to using PVH VMs, but at the moment this is not feasible.
In our testing, we found that pass-through PCI devices did not work in HVMs on some machines.
On the affected machines, networking devices and USB devices, for example, were not usable as they are in Qubes 3.2.
(The kernel driver failed to initialize the device.)
This was a major problem that would have blocked us from moving entirely from PV to HVM in Qubes 4.0.
For this reason, the Qubes 4.0-rc1 installer configures all VMs that have attached PCI devices to use PV mode so that those PCI devices will function correctly.
Problems
After much further testing, we discovered that the affected PCI devices don’t work without MSI support.
(MSI is a method to trigger an interrupt from a PCI device.)
The devices we observed to be problematic were all newer Intel devices (integrated USB controllers and a Wi-Fi card).
While the PCIe standard allows for devices that don’t support legacy interrupts, all the affected devices advertised support for legacy interrupts.
But no interrupts were ever delivered after the driver configured the device.
This made the bug tricky to track down, since we were looking for an error on the software side.
To get those devices working, we needed MSI support.
When running QEMU in dom0, MSI support (and therefore the problematic devices) worked, but with stub domains, it was broken.
This is why, until now, we’ve had patches in place to hide MSI capability from the guest so that the driver doesn’t try to use it (one patch for the Mini-OS-based stub domain (https://github.com/QubesOS/qubes-vmm-xen/blob/ff5eaaa777e9d6ba42242479d1cabacfbdc728ca/patches.misc/hvmpt02-disable-msi-caps.patch) and another for the new Linux-based stub domain (https://github.com/QubesOS/qubes-vmm-xen-stubdom-linux/blob/71a01b41a9cf69d580c652a7147c0a8eb33ced97/qemu/patches/disable-msi-caps.patch)).
We found two issues that were preventing MSI support from working with stub domains.
First, the stub domain did not have the required permission on the IRQ, which is reserved for the MSI in the map_pirq hypercall QEMU makes.
(The IRQ is basically a number to distinguish between interrupts from different devices.)
Fortunately, this problem had already been tracked down by OpenXT (http://openxt.org/), and they made a patch for it (the original (https://github.com/OpenXT/xenclient-oe/blob/5e0e7304a5a3c75ef01240a1e3673665b2aaf05e/recipes-extended/xen/files/stubdomain-msi-irq-access.patch) and our pull request (https://github.com/QubesOS/qubes-vmm-xen/pull/15/commits/2a5229f24296347a40ba3250465a61ca425a6146) based on their patch).
The second problem was that, after setting MSI up, it needed to be enabled.
This is done by setting the MSI enable flag in the PCI config space, which is a special memory mapped region used to configure a PCI device.
However, this write did not reach the device, and therefore no interrupts were delivered.
When running in dom0, the config space write from QEMU goes directly to the real PCI device.
By contrast, inside a stub domain, the write goes to the pcifront driver inside the stub domain and is then blocked by the pciback running in dom0.
With a test patch, we verified that the only problem was with the enable flag write.
No other config space writes were problematic.
Solutions
It appeared that we had to choose from the following options:
Enable permissive mode.
In permissive mode, pciback allows (almost) all writes to the PCI config space.
This seems to be the solution OpenXT chose (see this issue (https://openxt.atlassian.net/browse/OXT-894) and this commit (https://github.com/OpenXT/manager/pull/52/commits/5950ebe73f2411f3af37f5dd56c5c70619e5d99f)).
Allow just the write to this specific config space location (i.e. the enable flag).
Unlike option (1), this option entails allowing only the required write and no others.
Since pcifront has the ability to issue a specific command to pciback to enable MSI, maybe QEMU should send this command instead of the write to the config space.
Something else.
For example, maybe the MSI config should not be handled by QEMU at all in the case of stub domains but should instead be handled directly by Xen.
Option (3) didn’t appear promising.
The enable command that pcifront sends is intended for the normal PV use case where the device is passed to the VM itself (via pcifront) rather than to the stub domain target.
While the command is called enable_msi, pciback does much more than simply setting the enable flag.
It also configures IRQ handling in the dom0 kernel, adapts the MSI masking, and more.
This makes sense in the PV case, but in the HVM case, the MSI configuration is done by QEMU, so this most likely won’t work correctly.
Option (1) would have been the easiest solution.
We would just need to set the option in the domain config.
After discussing it, however, we weren’t convinced that this option is safe (but we also don’t claim it isn’t).
See the paper discussed below and this thread (https://lists.xenproject.org/archives/html/xen-devel/2010-07/msg00257.html) for some potential problems.
So, what about option (2)?
We had to think about whether this might enable a new attack.
If we were to implement option (2), the security scenario would be different from the scenario in which QEMU runs in dom0.
When QEMU runs in dom0, it ensures that MSI is configured in a certain way before enabling MSIs (details (https://git.qemu.org/?p=qemu.git;a=blob;f=hw/xen/xen_pt_config_init.c;h=6f18366f6768ee3d7b72f588dc990a6329124a04;hb=359c41abe32638adad503e386969fa428cecff52#l1114)).
However, we’ve put QEMU in a stub domain so that we don’t have to trust it.
This means that we can no longer trust it to ensure that MSI is configured safely.
What would happen if, for example, a malicious stub domain were to set the enable flag of a PCI device without first configuring it?
As it turns out, ITL has published research relevant to assessing this risk.
The second problem was that, after setting MSI up, it needed to be enabled.
This is done by setting the MSI enable flag in the PCI config space, which is a special memory mapped region used to configure a PCI device.
However, this write did not reach the device, and therefore no interrupts were delivered.
When running in dom0, the config space write from QEMU goes directly to the real PCI device.
By contrast, inside a stub domain, the write goes to the pcifront driver inside the stub domain and is then blocked by the pciback running in dom0.
With a test patch, we verified that the only problem was with the enable flag write.
No other config space writes were problematic.
Solutions
It appeared that we had to choose from the following options:
Enable permissive mode.
In permissive mode, pciback allows (almost) all writes to the PCI config space.
This seems to be the solution OpenXT chose (see this issue (https://openxt.atlassian.net/browse/OXT-894) and this commit (https://github.com/OpenXT/manager/pull/52/commits/5950ebe73f2411f3af37f5dd56c5c70619e5d99f)).
Allow just the write to this specific config space location (i.e. the enable flag).
Unlike option (1), this option entails allowing only the required write and no others.
Since pcifront has the ability to issue a specific command to pciback to enable MSI, maybe QEMU should send this command instead of the write to the config space.
Something else.
For example, maybe the MSI config should not be handled by QEMU at all in the case of stub domains but should instead be handled directly by Xen.
Option (3) didn’t appear promising.
The enable command that pcifront sends is intended for the normal PV use case where the device is passed to the VM itself (via pcifront) rather than to the stub domain target.
While the command is called enable_msi, pciback does much more than simply setting the enable flag.
It also configures IRQ handling in the dom0 kernel, adapts the MSI masking, and more.
This makes sense in the PV case, but in the HVM case, the MSI configuration is done by QEMU, so this most likely won’t work correctly.
Option (1) would have been the easiest solution.
We would just need to set the option in the domain config.
After discussing it, however, we weren’t convinced that this option is safe (but we also don’t claim it isn’t).
See the paper discussed below and this thread (https://lists.xenproject.org/archives/html/xen-devel/2010-07/msg00257.html) for some potential problems.
So, what about option (2)?
We had to think about whether this might enable a new attack.
If we were to implement option (2), the security scenario would be different from the scenario in which QEMU runs in dom0.
When QEMU runs in dom0, it ensures that MSI is configured in a certain way before enabling MSIs (details (https://git.qemu.org/?p=qemu.git;a=blob;f=hw/xen/xen_pt_config_init.c;h=6f18366f6768ee3d7b72f588dc990a6329124a04;hb=359c41abe32638adad503e386969fa428cecff52#l1114)).
However, we’ve put QEMU in a stub domain so that we don’t have to trust it.
This means that we can no longer trust it to ensure that MSI is configured safely.
What would happen if, for example, a malicious stub domain were to set the enable flag of a PCI device without first configuring it?
As it turns out, ITL has published research relevant to assessing this risk.
In “Following the White Rabbit: Software attacks against Intel(R) VT-d technology” (https://invisiblethingslab.com/resources/2011/Software%20Attacks%20on%20Intel%20VT-d.pdf), Rafał Wojtczuk and Joanna Rutkowska describe an attack against VT-d on machines without interrupt remapping support.
For our purposes, the result they describe on page 8 is very important:
Even without access to the PCI config space, a malicious guest is, in many cases, able to generate arbitrary MSIs.
So long as writing to the MSI enable flag does not have any unrelated side effects, there’s no obvious way in which allowing it can worsen security, since an attacker who can set it can already generate arbitrary MSIs anyway.
Meanwhile, we reap the benefits of using HVMs to better isolate VMs with attached PCI devices.
So, we decided to implement option (2).
Based on the analysis above, one could argue that we might as well allow writes to the enable flags for all VMs with attached PCI devices, since doing so shouldn’t decrease security.
To be extra cautious, however, we only allow writes to the enable flags for stub domains.
In other cases, it’s not necessary.
(Here are our patches for pciback (https://github.com/QubesOS/qubes-linux-kernel/pull/12/commits/96b956b38cb24230848a563d3e1ce359c8d8db66) and libxl (https://github.com/QubesOS/qubes-vmm-xen/pull/15/commits/55ef595451d9e2e5583a31c4a3600507ae5500f7).)
Now, the previously problematic devices function correctly inside HVMs.
(Here are the full pull requests: 1 (https://github.com/QubesOS/qubes-linux-kernel/pull/12), 2 (https://github.com/QubesOS/qubes-vmm-xen/pull/15), 3 (https://github.com/QubesOS/qubes-vmm-xen-stubdom-linux/pull/3).)
We just merged this feature, and it will be included in Qubes 4.0-rc2, which we plan to release next week.
After these patches undergo further testing, we plan to upstream them so that all Xen users can benefit from our work.
If you have any questions or comments, please write to us on qubes-devel (https://www.qubes-os.org/mailing-lists/#qubes-devel).
*We’ve switch from the Mini-OS-based stub domain to a Linux-based stub domain in Qubes 4.0 based on patches (https://lists.xenproject.org/archives/html/xen-devel/2015-02/msg00426.html) from Anthony Perad and Eric Shelton.
The switch is not significant for the purposes of this article.
For our purposes, the result they describe on page 8 is very important:
Even without access to the PCI config space, a malicious guest is, in many cases, able to generate arbitrary MSIs.
So long as writing to the MSI enable flag does not have any unrelated side effects, there’s no obvious way in which allowing it can worsen security, since an attacker who can set it can already generate arbitrary MSIs anyway.
Meanwhile, we reap the benefits of using HVMs to better isolate VMs with attached PCI devices.
So, we decided to implement option (2).
Based on the analysis above, one could argue that we might as well allow writes to the enable flags for all VMs with attached PCI devices, since doing so shouldn’t decrease security.
To be extra cautious, however, we only allow writes to the enable flags for stub domains.
In other cases, it’s not necessary.
(Here are our patches for pciback (https://github.com/QubesOS/qubes-linux-kernel/pull/12/commits/96b956b38cb24230848a563d3e1ce359c8d8db66) and libxl (https://github.com/QubesOS/qubes-vmm-xen/pull/15/commits/55ef595451d9e2e5583a31c4a3600507ae5500f7).)
Now, the previously problematic devices function correctly inside HVMs.
(Here are the full pull requests: 1 (https://github.com/QubesOS/qubes-linux-kernel/pull/12), 2 (https://github.com/QubesOS/qubes-vmm-xen/pull/15), 3 (https://github.com/QubesOS/qubes-vmm-xen-stubdom-linux/pull/3).)
We just merged this feature, and it will be included in Qubes 4.0-rc2, which we plan to release next week.
After these patches undergo further testing, we plan to upstream them so that all Xen users can benefit from our work.
If you have any questions or comments, please write to us on qubes-devel (https://www.qubes-os.org/mailing-lists/#qubes-devel).
*We’ve switch from the Mini-OS-based stub domain to a Linux-based stub domain in Qubes 4.0 based on patches (https://lists.xenproject.org/archives/html/xen-devel/2015-02/msg00426.html) from Anthony Perad and Eric Shelton.
The switch is not significant for the purposes of this article.
New article by Qubes team member Simon Gaiser (HW42): "MSI support for PCI device pass-through with stub domains"
https://t.co/eDVzduPoWY
https://t.co/eDVzduPoWY
Qubes OS
MSI support for PCI device pass-through with stub domains
Introduction In this post, we will describe how we fixed MSI support for VMs running in HVM mode in Qubes 4.0. First, allow us to provide some background about the MSI feature and why we need it i...
Announcing the Xen Project 4.10 RC and Test Day Schedules
https://blog.xenproject.org/2017/10/19/announcing-the-xen-project-4-10-rc-and-test-day-schedules/
On Monday, we created Xen 4.10 RC1 and will release a new release candidate every MONDAY, until we declare a release candidate as the final candidate and cut the Xen 4.10 release. We will also hold a Test Day every WEDNESDAY for the release candidate that was released the week prior to the Test Day […]
https://blog.xenproject.org/2017/10/19/announcing-the-xen-project-4-10-rc-and-test-day-schedules/
On Monday, we created Xen 4.10 RC1 and will release a new release candidate every MONDAY, until we declare a release candidate as the final candidate and cut the Xen 4.10 release. We will also hold a Test Day every WEDNESDAY for the release candidate that was released the week prior to the Test Day […]
Qubes OS 4.0-rc2 has been released!
https://www.qubes-os.org/news/2017/10/23/qubes-40-rc2/
We’re pleased to announce the second release candidate for Qubes 4.0! As usual,
this release candidate includes numerous bug fixes over the
previous one (https://www.qubes-os.org/news/2017/07/31/qubes-40-rc1/).
Two of the most important changes are:
Improved PCI passthrough (https://www.qubes-os.org/news/2017/10/18/msi-support/) with sys-net and sys-usb running in
HVM mode by default. With this change, we’ve officially achieved our
Qubes 4.0 goal (https://www.qubes-os.org/news/2016/07/21/new-hw-certification-for-q4/) of having all qubes running in HVM mode by
default for enhanced security.
Whonix templates are back! We’ve fixed various (https://phabricator.whonix.org/T697)
blocking (https://phabricator.whonix.org/T710) issues (https://phabricator.whonix.org/T491), and the Whonix templates are
available in the default installer once again. We’re even debuting new
Whonix-based DispVMs!
There were two primary reasons for the substantial delay (https://www.qubes-os.org/doc/releases/4.0/schedule/) of this
release. The first was our discovery of the security issue (https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-034-2017.txt) that would
come to be known as XSA-237 (https://xenbits.xen.org/xsa/advisory-237.html). As part of our coordination with the Xen Project
Security Team, we had to wait through the embargo period until XSA-237 was
publicly released before integrating various PCI passthrough fixes.
The second reason for the delay was the last-minute discovery of a bug related
to resizing the root filesystem of a qube. We faced a choice (https://groups.google.com/d/msgid/qubes-devel/20171013222228.GF10749%40mail-itl)
between (1) keeping the partition layout the same at the cost of increasing
maintenance complexity in the future or (2) changing the partition layout to
simplify the code at the cost of rebuilding all the templates and delaying the
release. We chose (https://groups.google.com/d/msgid/qubes-devel/20171016134524.GI1059%40mail-itl) the second option, which resulted in an
additional one week delay, but we’re confident that this is the most prudent
move in the long run.
As a consequence of the partition layout change, it will be necessary for
current 4.0-rc1 testers to perform a clean reinstall of 4.0-rc2 rather than
attempting to upgrade in-place. We sincerely apologize for this inconvenience.
Our growing community has been putting in a lot of hard work testing the first
4.0 release candidate and submitting bug reports, and we greatly appreciate your
effort. From the whole Qubes team, thank you! Your feedback helps us make the
final release as stable as possible. Please keep up the great work!
Further details, including full installation and update instructions,
are available in the Qubes 4.0 release notes (https://www.qubes-os.org/doc/releases/4.0/release-notes/). The new
installation image is available on the Downloads (https://www.qubes-os.org/downloads/) page.
https://www.qubes-os.org/news/2017/10/23/qubes-40-rc2/
We’re pleased to announce the second release candidate for Qubes 4.0! As usual,
this release candidate includes numerous bug fixes over the
previous one (https://www.qubes-os.org/news/2017/07/31/qubes-40-rc1/).
Two of the most important changes are:
Improved PCI passthrough (https://www.qubes-os.org/news/2017/10/18/msi-support/) with sys-net and sys-usb running in
HVM mode by default. With this change, we’ve officially achieved our
Qubes 4.0 goal (https://www.qubes-os.org/news/2016/07/21/new-hw-certification-for-q4/) of having all qubes running in HVM mode by
default for enhanced security.
Whonix templates are back! We’ve fixed various (https://phabricator.whonix.org/T697)
blocking (https://phabricator.whonix.org/T710) issues (https://phabricator.whonix.org/T491), and the Whonix templates are
available in the default installer once again. We’re even debuting new
Whonix-based DispVMs!
There were two primary reasons for the substantial delay (https://www.qubes-os.org/doc/releases/4.0/schedule/) of this
release. The first was our discovery of the security issue (https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-034-2017.txt) that would
come to be known as XSA-237 (https://xenbits.xen.org/xsa/advisory-237.html). As part of our coordination with the Xen Project
Security Team, we had to wait through the embargo period until XSA-237 was
publicly released before integrating various PCI passthrough fixes.
The second reason for the delay was the last-minute discovery of a bug related
to resizing the root filesystem of a qube. We faced a choice (https://groups.google.com/d/msgid/qubes-devel/20171013222228.GF10749%40mail-itl)
between (1) keeping the partition layout the same at the cost of increasing
maintenance complexity in the future or (2) changing the partition layout to
simplify the code at the cost of rebuilding all the templates and delaying the
release. We chose (https://groups.google.com/d/msgid/qubes-devel/20171016134524.GI1059%40mail-itl) the second option, which resulted in an
additional one week delay, but we’re confident that this is the most prudent
move in the long run.
As a consequence of the partition layout change, it will be necessary for
current 4.0-rc1 testers to perform a clean reinstall of 4.0-rc2 rather than
attempting to upgrade in-place. We sincerely apologize for this inconvenience.
Our growing community has been putting in a lot of hard work testing the first
4.0 release candidate and submitting bug reports, and we greatly appreciate your
effort. From the whole Qubes team, thank you! Your feedback helps us make the
final release as stable as possible. Please keep up the great work!
Further details, including full installation and update instructions,
are available in the Qubes 4.0 release notes (https://www.qubes-os.org/doc/releases/4.0/release-notes/). The new
installation image is available on the Downloads (https://www.qubes-os.org/downloads/) page.
RT @josephfcox: Qubes releases version 4.0-rc2. Includes disposable Whonix VMs; for when you want to be anonymous and ephemeral https://t.co/Q8jJqoCjC5 https://t.co/7avM2L0l2i
Qubes OS
Qubes OS 4.0-rc2 has been released!
We’re pleased to announce the second release candidate for Qubes 4.0! As usual, this release candidate includes numerous bug fixes over the previous one. Two of the most important changes are: ...
Qubes Security Bulletin #35:
Xen hypervisor issue related to grant tables (XSA-236)
https://t.co/dY3o3KmPCo
Xen hypervisor issue related to grant tables (XSA-236)
https://t.co/dY3o3KmPCo
GitHub
QubesOS/qubes-secpack
qubes-secpack - Qubes Security Pack
QSB #35: Xen hypervisor issue related to grant tables (XSA-236)
https://www.qubes-os.org/news/2017/10/25/qsb-35/
Dear Qubes Community,
We have published Qubes Security Bulletin (QSB) #35:
Xen hypervisor issue related to grant tables (XSA-236).
The text of this QSB is reproduced below. This QSB and its accompanying
signatures will always be available in the Qubes Security Pack (qubes-secpack).
View QSB #35 in the qubes-secpack:
https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-035-2017.txt
Learn about the qubes-secpack, including how to obtain, verify, and read it:
https://www.qubes-os.org/security/pack/
View all past QSBs:
https://www.qubes-os.org/security/bulletins/
View XSA-236 in the XSA Tracker:
https://www.qubes-os.org/security/xsa/#236
---===[ Qubes Security Bulletin #35 ]===---
October 24, 2017
Xen hypervisor issue related to grant tables (XSA-236)
Summary
========
The Xen Security Team has published Xen Security Advisory 236, which
concerns an issue with the grant tables mechanism used to share memory
between domains. The practical impact of this advisory is believed to
be denial of service only. However, privilege escalation and information
leaks are theoretically possible.
Technical details
==================
Xen Security Advisory 236 [1]:
| Grant copying code made an implication that any grant pin would be
| accompanied by a suitable page reference. Other portions of code,
| however, did not match up with that assumption. When such a grant
| copy operation is being done on a grant of a dying domain, the
| assumption turns out wrong.
|
| A malicious guest administrator can cause hypervisor memory
| corruption, most likely resulting in host crash and a Denial of
| Service. Privilege escalation and information leaks cannot be ruled
| out.
Compromise Recovery
====================
Beginning with Qubes 3.2, we offer Paranoid Backup Restore Mode, which
was designed specifically to aid in the recovery of a potentially
compromised Qubes OS system. If you believe your system may be
compromised (perhaps because of the issue discussed in this bulletin),
please read and follow the procedure described here:
https://www.qubes-os.org/news/2017/04/26/qubes-compromise-recovery/
Patching
=========
The specific packages that resolve the problem discussed in this
bulletin are as follows:
For Qubes 3.2:
- Xen packages, version 4.6.6-34
For Qubes 4.0:
- Xen packages, version 4.8.2-9
The packages are to be installed in dom0 via the Qubes VM Manager or via
the qubes-dom0-update command as follows:
For updates from the stable repository (not immediately available):
$ sudo qubes-dom0-update
For updates from the security-testing repository:
$ sudo qubes-dom0-update --enablerepo=qubes-dom0-security-testing
A system restart will be required afterwards.
These packages will migrate from the security-testing repository to the
current (stable) repository over the next two weeks after being tested
by the community.
If you use Anti Evil Maid, you will need to reseal your secret
passphrase to new PCR values, as PCR18+19 will change due to the new
Xen binaries.
Credits
========
See the original Xen Security Advisory.
References
===========
[1] https://xenbits.xen.org/xsa/advisory-236.html
--
The Qubes Security Team
https://www.qubes-os.org/security/
https://www.qubes-os.org/news/2017/10/25/qsb-35/
Dear Qubes Community,
We have published Qubes Security Bulletin (QSB) #35:
Xen hypervisor issue related to grant tables (XSA-236).
The text of this QSB is reproduced below. This QSB and its accompanying
signatures will always be available in the Qubes Security Pack (qubes-secpack).
View QSB #35 in the qubes-secpack:
https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-035-2017.txt
Learn about the qubes-secpack, including how to obtain, verify, and read it:
https://www.qubes-os.org/security/pack/
View all past QSBs:
https://www.qubes-os.org/security/bulletins/
View XSA-236 in the XSA Tracker:
https://www.qubes-os.org/security/xsa/#236
---===[ Qubes Security Bulletin #35 ]===---
October 24, 2017
Xen hypervisor issue related to grant tables (XSA-236)
Summary
========
The Xen Security Team has published Xen Security Advisory 236, which
concerns an issue with the grant tables mechanism used to share memory
between domains. The practical impact of this advisory is believed to
be denial of service only. However, privilege escalation and information
leaks are theoretically possible.
Technical details
==================
Xen Security Advisory 236 [1]:
| Grant copying code made an implication that any grant pin would be
| accompanied by a suitable page reference. Other portions of code,
| however, did not match up with that assumption. When such a grant
| copy operation is being done on a grant of a dying domain, the
| assumption turns out wrong.
|
| A malicious guest administrator can cause hypervisor memory
| corruption, most likely resulting in host crash and a Denial of
| Service. Privilege escalation and information leaks cannot be ruled
| out.
Compromise Recovery
====================
Beginning with Qubes 3.2, we offer Paranoid Backup Restore Mode, which
was designed specifically to aid in the recovery of a potentially
compromised Qubes OS system. If you believe your system may be
compromised (perhaps because of the issue discussed in this bulletin),
please read and follow the procedure described here:
https://www.qubes-os.org/news/2017/04/26/qubes-compromise-recovery/
Patching
=========
The specific packages that resolve the problem discussed in this
bulletin are as follows:
For Qubes 3.2:
- Xen packages, version 4.6.6-34
For Qubes 4.0:
- Xen packages, version 4.8.2-9
The packages are to be installed in dom0 via the Qubes VM Manager or via
the qubes-dom0-update command as follows:
For updates from the stable repository (not immediately available):
$ sudo qubes-dom0-update
For updates from the security-testing repository:
$ sudo qubes-dom0-update --enablerepo=qubes-dom0-security-testing
A system restart will be required afterwards.
These packages will migrate from the security-testing repository to the
current (stable) repository over the next two weeks after being tested
by the community.
If you use Anti Evil Maid, you will need to reseal your secret
passphrase to new PCR values, as PCR18+19 will change due to the new
Xen binaries.
Credits
========
See the original Xen Security Advisory.
References
===========
[1] https://xenbits.xen.org/xsa/advisory-236.html
--
The Qubes Security Team
https://www.qubes-os.org/security/
RT @okayultra: LOL, @QubesOS and its painful-but-necessary clipboard isolation has prevented literally hundreds such incidents for me. https://t.co/aLNP9vXJ8X
Twitter
Adrienne Porter Felt
Ummmmmm I accidentally emailed this comic to several contractors instead of our building plans
Thank you Peter for you continued support! https://t.co/hLdDqAUZej
Twitter
Peter Todd
Donated a % of my consulting company's last year revenue to @QubesOS I rely on it for all my work, and recommend it to clients too.
Forwarded from Qubes OS
Join the group!
Rules:
>No spam/ads/NSFW/shit posts
>Keep media like/stickers to a minimum.
>Respect others
>Use common sense
>Stay on topic
If you need help please ask!
Rules are enforced with ban or restrictions.
Link:
t.me/joinchat/B8FHpkEToMeDRgQ_cI60XQ
Rules:
>No spam/ads/NSFW/shit posts
>Keep media like/stickers to a minimum.
>Respect others
>Use common sense
>Stay on topic
If you need help please ask!
Rules are enforced with ban or restrictions.
Link:
t.me/joinchat/B8FHpkEToMeDRgQ_cI60XQ
RT @B_Meson: @micahflee correct me if I’m wrong but also won’t effect you if you use Qubes with a Whonix VM https://t.co/K43SHLOMlM
Twitter
Ars Technica
Critical Tor flaw leaks users’ real IP address—update now https://t.co/SmwqDmywV3 by @dangoodin001
RT @ttaskett: Another reason to run @QubesOS: Linux vulnerable to USB devices. #badusb #infosec
https://t.co/u56UAAbAzw
https://t.co/u56UAAbAzw
BleepingComputer
Linux Has a USB Driver Security Problem
USB drivers included in the Linux kernel are rife with security flaws that in some cases can be exploited to run untrusted code and take over users' computers.
RT @rootkovska: Nobody! The whole point of @QubesOS is that we don't need to trust the USB drivers :)
#SecurityThroughDistrusting https://t.co/xOJP6vK0ZP
#SecurityThroughDistrusting https://t.co/xOJP6vK0ZP
Twitter
Worship The Fallen
@ttaskett @QubesOS Which USB drivers is @QubesOS using? Who audited them?
Xen Project Membership Spotlight: Citrix
https://blog.xenproject.org/2017/11/21/xen-project-membership-spotlight-citrix/
The Xen Project is comprised of a diverse set of member companies and contributors that are committed to the growth and success of the Xen Project Hypervisor. The Xen Project Hypervisor is a staple technology for server and cloud vendors, and is gaining traction in the embedded, security and automotive space. This blog series highlights […]
https://blog.xenproject.org/2017/11/21/xen-project-membership-spotlight-citrix/
The Xen Project is comprised of a diverse set of member companies and contributors that are committed to the growth and success of the Xen Project Hypervisor. The Xen Project Hypervisor is a staple technology for server and cloud vendors, and is gaining traction in the embedded, security and automotive space. This blog series highlights […]
Comment on What’s New in the Xen Project Hypervisor 4.9? by hopperyelena
https://blog.xenproject.org/2017/06/28/whats-new-in-the-xen-project-hypervisor-4-9/#comment-408
I Have the same question..
https://blog.xenproject.org/2017/06/28/whats-new-in-the-xen-project-hypervisor-4-9/#comment-408
I Have the same question..
Xen Project 4.7.4 and 4.9.1 are available
https://blog.xenproject.org/2017/11/27/xen-project-4-7-4-and-4-9-1-are-available/
I am pleased to announce the release of Xen 4.7.4 and 4.9.1. Xen Project Maintenance releases are released in line with our Maintenance Release Policy. We recommend that all users of the 4.7 and 4.9 stable series update to the latest point release. These releases are available from their git repositories xenbits.xen.org/gitweb/?p=xen.git;a=shortlog;h=refs/heads/stable-4.7 (tag RELEASE-4.7.4) xenbits.xen.org/gitweb/?p=xen.git;a=shortlog;h=refs/heads/stable-4.9 […]
https://blog.xenproject.org/2017/11/27/xen-project-4-7-4-and-4-9-1-are-available/
I am pleased to announce the release of Xen 4.7.4 and 4.9.1. Xen Project Maintenance releases are released in line with our Maintenance Release Policy. We recommend that all users of the 4.7 and 4.9 stable series update to the latest point release. These releases are available from their git repositories xenbits.xen.org/gitweb/?p=xen.git;a=shortlog;h=refs/heads/stable-4.7 (tag RELEASE-4.7.4) xenbits.xen.org/gitweb/?p=xen.git;a=shortlog;h=refs/heads/stable-4.9 […]