Get paid to support Qubes development through automated testing! (three-month contract)
https://www.qubes-os.org/news/2020/09/20/get-paid-to-support-qubes-development-through-automated-testing/
The Qubes OS Project is seeking an expert in automated testing. We use
OpenQA and Travis to test changes to the Qubes OS source code and
automated building from source. We’re looking for someone who can help
with improving both the automated tests themselves and the testing
infrastructure.
This is a paid position on a three-month part-time contract through the
Internews BASICS project (Building Analytical and Support Infrastructure
for Critical Security tools):
https://chm.tbe.taleo.net/chm04/ats/careers/v2/viewRequisition?org=INTERNEWS&cws=38&rid=1186
https://www.qubes-os.org/news/2020/09/20/get-paid-to-support-qubes-development-through-automated-testing/
The Qubes OS Project is seeking an expert in automated testing. We use
OpenQA and Travis to test changes to the Qubes OS source code and
automated building from source. We’re looking for someone who can help
with improving both the automated tests themselves and the testing
infrastructure.
This is a paid position on a three-month part-time contract through the
Internews BASICS project (Building Analytical and Support Infrastructure
for Critical Security tools):
https://chm.tbe.taleo.net/chm04/ats/careers/v2/viewRequisition?org=INTERNEWS&cws=38&rid=1186
QSB #059: Multiple Xen issues (XSA-337, XSA-340, XSA-343)
https://www.qubes-os.org/news/2020/09/22/qsb-059/
We have just published Qubes Security Bulletin (QSB) #059:
Multiple Xen issues (XSA-337, XSA-340, XSA-343).
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 #059 in the qubes-secpack:
https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-059-2020.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 the associated XSAs in the XSA Tracker:
https://www.qubes-os.org/security/xsa/#337
https://www.qubes-os.org/security/xsa/#340
https://www.qubes-os.org/security/xsa/#343
---===[ Qubes Security Bulletin #59 ]===---
2020-09-22
Multiple Xen issues (XSA-337, XSA-340, XSA-343)
Summary
========
On 2020-09-22, the Xen Security Team published the following Xen
Security Advisories (XSAs):
XSA-337 [1] "PCI passthrough code reading back hardware registers":
| Code paths in Xen's MSI handling have been identified which act on
| unsanitized values read back from device hardware registers. While
| devices strictly compliant with PCI specifications shouldn't be able
| to affect these registers, experience shows that it's very common for
| devices to have out-of-spec "backdoor" operations which can affect the
| result of these reads.
|
| A not fully trusted guest may be able to crash Xen, leading to a
| Denial of Service (DoS) for the entire system. Privilege escalation
| and information leaks cannot be excluded.
XSA-340 [2] "Missing memory barriers when accessing/allocating an event
channel":
| Event channels control structures can be accessed lockless as long as
| the port is considered to be valid. Such sequence is missing
| appropriate memory barrier (e.g smp_*mb()) to prevent both the
| compiler and CPU to re-order access.
|
| A malicious guest may be able to cause a hypervisor crash resulting in
| a Denial of Service (DoS). Information leak and privilege escalation
| cannot be excluded.
XSA-343 [3] "races with evtchn_reset()":
| Uses of EVTCHNOP_reset (potentially by a guest on itself) or
| XEN_DOMCTL_soft_reset (by itself covered by XSA-77) can lead to the
| violation of various internal assumptions. This may lead to out of
| bounds memory accesses or triggering of bug checks.
|
| In particular x86 PV guests may be able to elevate their privilege to
| that of the host. Host and guest crashes are also possible, leading
| to a Denial of Service (DoS). Information leaks cannot be ruled out.
Impact
=======
XSA-337: A malicious HVM with a PCI device (such as sys-net or sys-usb
in the default Qubes OS configuration) can potentially compromise the
whole system.
XSA-340: A malicious VM can exploit this vulnerability to crash Qubes
OS, resulting in a Denial of Service (DoS). This would require winning
a tight race condition. Beyond DoS, it is very unlikely that this
vulnerability could be exploited to compromise the system, but we
cannot completely rule out the possibility.
XSA-343: By default, Qubes OS uses PV domains only as stubdomains
hosting qemu for HVM domains. Therefore, in the default configuration,
an adversary cannot exploit this vulnerability directly. However, if an
adversary were also able to identify a complementary qemu vulnerability,
then chaining the attacks together could theoretically allow the
adversary to compromise the whole system. Although Qubes OS does not
contain any PV domains by default, users can create them manually by
setting the virt_mode property to PV. Such domains can exploit this
vulnerability directly.
Patching
=========
The specific packages that resolve the problems discussed in this
bulletin are as follows:
For Qubes 4.0:
- Xen packages, version 4.8.5-23
https://www.qubes-os.org/news/2020/09/22/qsb-059/
We have just published Qubes Security Bulletin (QSB) #059:
Multiple Xen issues (XSA-337, XSA-340, XSA-343).
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 #059 in the qubes-secpack:
https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-059-2020.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 the associated XSAs in the XSA Tracker:
https://www.qubes-os.org/security/xsa/#337
https://www.qubes-os.org/security/xsa/#340
https://www.qubes-os.org/security/xsa/#343
---===[ Qubes Security Bulletin #59 ]===---
2020-09-22
Multiple Xen issues (XSA-337, XSA-340, XSA-343)
Summary
========
On 2020-09-22, the Xen Security Team published the following Xen
Security Advisories (XSAs):
XSA-337 [1] "PCI passthrough code reading back hardware registers":
| Code paths in Xen's MSI handling have been identified which act on
| unsanitized values read back from device hardware registers. While
| devices strictly compliant with PCI specifications shouldn't be able
| to affect these registers, experience shows that it's very common for
| devices to have out-of-spec "backdoor" operations which can affect the
| result of these reads.
|
| A not fully trusted guest may be able to crash Xen, leading to a
| Denial of Service (DoS) for the entire system. Privilege escalation
| and information leaks cannot be excluded.
XSA-340 [2] "Missing memory barriers when accessing/allocating an event
channel":
| Event channels control structures can be accessed lockless as long as
| the port is considered to be valid. Such sequence is missing
| appropriate memory barrier (e.g smp_*mb()) to prevent both the
| compiler and CPU to re-order access.
|
| A malicious guest may be able to cause a hypervisor crash resulting in
| a Denial of Service (DoS). Information leak and privilege escalation
| cannot be excluded.
XSA-343 [3] "races with evtchn_reset()":
| Uses of EVTCHNOP_reset (potentially by a guest on itself) or
| XEN_DOMCTL_soft_reset (by itself covered by XSA-77) can lead to the
| violation of various internal assumptions. This may lead to out of
| bounds memory accesses or triggering of bug checks.
|
| In particular x86 PV guests may be able to elevate their privilege to
| that of the host. Host and guest crashes are also possible, leading
| to a Denial of Service (DoS). Information leaks cannot be ruled out.
Impact
=======
XSA-337: A malicious HVM with a PCI device (such as sys-net or sys-usb
in the default Qubes OS configuration) can potentially compromise the
whole system.
XSA-340: A malicious VM can exploit this vulnerability to crash Qubes
OS, resulting in a Denial of Service (DoS). This would require winning
a tight race condition. Beyond DoS, it is very unlikely that this
vulnerability could be exploited to compromise the system, but we
cannot completely rule out the possibility.
XSA-343: By default, Qubes OS uses PV domains only as stubdomains
hosting qemu for HVM domains. Therefore, in the default configuration,
an adversary cannot exploit this vulnerability directly. However, if an
adversary were also able to identify a complementary qemu vulnerability,
then chaining the attacks together could theoretically allow the
adversary to compromise the whole system. Although Qubes OS does not
contain any PV domains by default, users can create them manually by
setting the virt_mode property to PV. Such domains can exploit this
vulnerability directly.
Patching
=========
The specific packages that resolve the problems discussed in this
bulletin are as follows:
For Qubes 4.0:
- Xen packages, version 4.8.5-23
For Qubes 4.1:
- Xen packages, version 4.14.0-4
The packages are to be installed in dom0 via the Qube 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-337.html
[1] https://xenbits.xen.org/xsa/advisory-340.html
[1] https://xenbits.xen.org/xsa/advisory-343.html
--
The Qubes Security Team
https://www.qubes-os.org/security/
- Xen packages, version 4.14.0-4
The packages are to be installed in dom0 via the Qube 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-337.html
[1] https://xenbits.xen.org/xsa/advisory-340.html
[1] https://xenbits.xen.org/xsa/advisory-343.html
--
The Qubes Security Team
https://www.qubes-os.org/security/
XSAs 333, 334, 336, 338, 339, 342, and 344 do not affect the security of Qubes OS
https://www.qubes-os.org/news/2020/09/22/xsa-333-334-336-338-339-342-344-qubes-not-affected/
The Xen Project has published the following Xen Security Advisories:
XSA-333, XSA-334, XSA-336, XSA-338, XSA-339, XSA-342, and XSA-344.
These XSAs do not affect the security of Qubes OS, and no user
action is necessary.
These XSAs have been added to the XSA Tracker (https://www.qubes-os.org/security/xsa/):
https://www.qubes-os.org/security/xsa/#333
https://www.qubes-os.org/security/xsa/#334
https://www.qubes-os.org/security/xsa/#336
https://www.qubes-os.org/security/xsa/#338
https://www.qubes-os.org/security/xsa/#339
https://www.qubes-os.org/security/xsa/#342
https://www.qubes-os.org/security/xsa/#344
https://www.qubes-os.org/news/2020/09/22/xsa-333-334-336-338-339-342-344-qubes-not-affected/
The Xen Project has published the following Xen Security Advisories:
XSA-333, XSA-334, XSA-336, XSA-338, XSA-339, XSA-342, and XSA-344.
These XSAs do not affect the security of Qubes OS, and no user
action is necessary.
These XSAs have been added to the XSA Tracker (https://www.qubes-os.org/security/xsa/):
https://www.qubes-os.org/security/xsa/#333
https://www.qubes-os.org/security/xsa/#334
https://www.qubes-os.org/security/xsa/#336
https://www.qubes-os.org/security/xsa/#338
https://www.qubes-os.org/security/xsa/#339
https://www.qubes-os.org/security/xsa/#342
https://www.qubes-os.org/security/xsa/#344
Xen on Raspberry Pi 4 adventures
https://xenproject.org/2020/09/29/xen-on-raspberry-pi-4-adventures/
The Xen Project is excited to share that the Xen Hypervisor now runs on Raspberry Pi. This is an exciting step for both hobbyists and industries. Read more to learn...
https://xenproject.org/2020/09/29/xen-on-raspberry-pi-4-adventures/
The Xen Project is excited to share that the Xen Hypervisor now runs on Raspberry Pi. This is an exciting step for both hobbyists and industries. Read more to learn...
Arm Contributions to Xen Based Safety Systems
https://xenproject.org/2020/10/05/arm-contributions-to-xen-based-safety-systems/
Arm, a member of the Xen project, has made valuable contributions to the Xen Project through the years. In this talk, Bertrand Marquis, Principal Software Engineer, Arm Ltd, highlights some...
https://xenproject.org/2020/10/05/arm-contributions-to-xen-based-safety-systems/
Arm, a member of the Xen project, has made valuable contributions to the Xen Project through the years. In this talk, Bertrand Marquis, Principal Software Engineer, Arm Ltd, highlights some...
Qubes OS contributed packages are now available
https://www.qubes-os.org/news/2020/10/05/qubes-os-contributed-packages/
We are happy to announce the availability of Qubes OS contributed packages under the QubesOS-contrib (https://github.com/QubesOS-contrib/) GitHub Project. This is a place where our community can contribute Qubes OS related packages, additions and various customizations (https://www.qubes-os.org/doc/package-contributions/). Meanwhile, we provide the infrastructure and review process (https://www.qubes-os.org/doc/package-contributions/#review-procedure) necessary to make them available easily and safely to users within standard Qubes installations.
Frédéric Pierret (https://www.qubes-os.org/team/#fr%C3%A9d%C3%A9ric-pierret) built the infrastructure based on a similar setup for building official packages. This means that it features the same Qubes build security (https://www.qubes-os.org/news/2016/05/30/build-security/) measures, including keeping the signing keys separate in a dedicated VM, downloading packages over Tor, publishing build logs in a non-spoofable way and more. Frédéric is also the maintainer of QubesOS-contrib (https://github.com/QubesOS-contrib/).
The source code repositories of the packages and infrastructure-related parts are also hosted under QubesOS-contrib (https://github.com/QubesOS-contrib/).
To contribute a package, follow the process described at package contributions (https://www.qubes-os.org/doc/package-contributions/). You will find a few helpful tips there, including a skeleton repository (https://github.com/QubesOS-contrib/qubes-skeleton/) with example RPM packaging and Qubes Builder (https://www.qubes-os.org/doc/qubes-builder/) integration.
Since the project has been running for some time already, there are already some submitted packages available there. To name a few:
qubes-tunnel (https://github.com/QubesOS-contrib/qubes-tunnel)
qvm-screenshot-tool (https://github.com/QubesOS-contrib/qvm-screenshot-tool)
qmenu (https://github.com/QubesOS-contrib/qmenu)
You can find the full list at QubesOS-contrib (https://github.com/QubesOS-contrib/).
If you want to install one of these packages, first you need to enable the repository in your system (dom0 and/or templates). This can be done by installing the qubes-repo-contrib package. This package includes the repository definition and keys necessary to download, verify, and install QubesOS-contrib (https://github.com/QubesOS-contrib/) packages.
In dom0, use qubes-dom0-update:
sudo qubes-dom0-update qubes-repo-contrib
In a Fedora-based template, use dnf:
sudo dnf install qubes-repo-contrib
In a Debian-based template, use apt:
sudo apt update && sudo apt install qubes-repo-contrib
https://www.qubes-os.org/news/2020/10/05/qubes-os-contributed-packages/
We are happy to announce the availability of Qubes OS contributed packages under the QubesOS-contrib (https://github.com/QubesOS-contrib/) GitHub Project. This is a place where our community can contribute Qubes OS related packages, additions and various customizations (https://www.qubes-os.org/doc/package-contributions/). Meanwhile, we provide the infrastructure and review process (https://www.qubes-os.org/doc/package-contributions/#review-procedure) necessary to make them available easily and safely to users within standard Qubes installations.
Frédéric Pierret (https://www.qubes-os.org/team/#fr%C3%A9d%C3%A9ric-pierret) built the infrastructure based on a similar setup for building official packages. This means that it features the same Qubes build security (https://www.qubes-os.org/news/2016/05/30/build-security/) measures, including keeping the signing keys separate in a dedicated VM, downloading packages over Tor, publishing build logs in a non-spoofable way and more. Frédéric is also the maintainer of QubesOS-contrib (https://github.com/QubesOS-contrib/).
The source code repositories of the packages and infrastructure-related parts are also hosted under QubesOS-contrib (https://github.com/QubesOS-contrib/).
To contribute a package, follow the process described at package contributions (https://www.qubes-os.org/doc/package-contributions/). You will find a few helpful tips there, including a skeleton repository (https://github.com/QubesOS-contrib/qubes-skeleton/) with example RPM packaging and Qubes Builder (https://www.qubes-os.org/doc/qubes-builder/) integration.
Since the project has been running for some time already, there are already some submitted packages available there. To name a few:
qubes-tunnel (https://github.com/QubesOS-contrib/qubes-tunnel)
qvm-screenshot-tool (https://github.com/QubesOS-contrib/qvm-screenshot-tool)
qmenu (https://github.com/QubesOS-contrib/qmenu)
You can find the full list at QubesOS-contrib (https://github.com/QubesOS-contrib/).
If you want to install one of these packages, first you need to enable the repository in your system (dom0 and/or templates). This can be done by installing the qubes-repo-contrib package. This package includes the repository definition and keys necessary to download, verify, and install QubesOS-contrib (https://github.com/QubesOS-contrib/) packages.
In dom0, use qubes-dom0-update:
sudo qubes-dom0-update qubes-repo-contrib
In a Fedora-based template, use dnf:
sudo dnf install qubes-repo-contrib
In a Debian-based template, use apt:
sudo apt update && sudo apt install qubes-repo-contrib
Calling all humans!
https://www.qubes-os.org/news/2020/10/09/calling-all-humans/
Greetings, Qubes community! We are running our first ever survey of current, former, and future Qubes OS users. We invite you all to lend us 10-15min of your time, to participate.
https://survey.qubes-os.org/index.php?r=survey/index&sid=791682&lang=en
The Qubes OS team loves the conversations we have with our community across forums, email lists, in support tickets, and at conferences. As most of us understand, though, structured data is very different — and clear information to help us make product and development decisions in the weeks and months to come, we feel is necessary to best serve our users.
This survey is also just the beginning of several weeks of user research work that will consist of interviews, user testing, co-creation workshop(s) with users guided by a ux specialist, and possibly more surveys. At the end of this survey, we’ll collect contact information should participating in that work be of interest to folks. We also look forward to keeping folks updated in our user communities, with how all of this work is progressing.
https://www.qubes-os.org/news/2020/10/09/calling-all-humans/
Greetings, Qubes community! We are running our first ever survey of current, former, and future Qubes OS users. We invite you all to lend us 10-15min of your time, to participate.
https://survey.qubes-os.org/index.php?r=survey/index&sid=791682&lang=en
The Qubes OS team loves the conversations we have with our community across forums, email lists, in support tickets, and at conferences. As most of us understand, though, structured data is very different — and clear information to help us make product and development decisions in the weeks and months to come, we feel is necessary to best serve our users.
This survey is also just the beginning of several weeks of user research work that will consist of interviews, user testing, co-creation workshop(s) with users guided by a ux specialist, and possibly more surveys. At the end of this survey, we’ll collect contact information should participating in that work be of interest to folks. We also look forward to keeping folks updated in our user communities, with how all of this work is progressing.
Xen Summit: Running Xen without Direct Map
https://xenproject.org/2020/10/13/xen-summit-running-xen-without-direct-map/
This talk was given by Hongyan Xia & David Woodhouse of Amazon at the 2020 Xen Project Developer and Design Summit. With the rising number of speculation vulnerabilities in CPUs,...
https://xenproject.org/2020/10/13/xen-summit-running-xen-without-direct-map/
This talk was given by Hongyan Xia & David Woodhouse of Amazon at the 2020 Xen Project Developer and Design Summit. With the rising number of speculation vulnerabilities in CPUs,...
QSB #060: Multiple Xen issues (XSA-345, XSA-346, XSA-347)
https://www.qubes-os.org/news/2020/10/20/qsb-060/
We have just published Qubes Security Bulletin (QSB) #060: Multiple Xen
issues (XSA-345, XSA-346, XSA-347). 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).
Special note: Although XSA-345 is included in this QSB, we do not
consider XSA-345 to affect the security of Qubes OS (https://www.qubes-os.org/news/2020/10/20/xsa-286-331-332-345-qubes-not-affected/),
since the default configuration is safe, and we have already implemented
appropriate safeguards to prevent users from changing to a vulnerable
configuration by accident. Please see the Impact section in QSB #060
below for further details.
View QSB #060 in the qubes-secpack:
https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-060-2020.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 the associated XSAs in the XSA Tracker:
https://www.qubes-os.org/security/xsa/#345
https://www.qubes-os.org/security/xsa/#346
https://www.qubes-os.org/security/xsa/#347
---===[ Qubes Security Bulletin #60 ]===---
2020-10-20
Multiple Xen issues (XSA-345, XSA-346, XSA-347)
Summary
========
On 2020-10-20, the Xen Security Team published the following Xen
Security Advisories (XSAs):
XSA-345 [1] "x86: Race condition in Xen mapping code":
| The Xen code handling the updating of the hypervisor's own pagetables
| tries to use 2MiB and 1GiB superpages as much as possible to maximize
| TLB efficiency. Some of the operations for checking and coalescing
| superpages take non-negligible amount of time; to avoid potential lock
| contention, this code also tries to avoid holding locks for the entire
| operation.
|
| Unfortunately, several potential race conditions were not considered;
| precisely-timed guest actions could potentially lead to the code
| writing to a page which has been freed (and thus potentially already
| reused).
|
| A malicious guest can cause a host denial-of-service. Data corruption
| or privilege escalation cannot be ruled out.
XSA-346 [2] "undue deferral of IOMMU TLB flushes":
| To efficiently change the physical to machine address mappings of a
| larger range of addresses for fully virtualized guests, Xen contains
| an optimization to coalesce per-page IOMMU TLB flushes into a single,
| wider flush after all adjustments have been made. While this is fine
| to do for newly introduced page mappings, the possible removal of
| pages from such guests during this operation should not be "optimized"
| in the same way. This is because the (typically) final reference of
| such pages is dropped before the coalesced flush, and hence the pages
| may have been put to a different use even though DMA initiated by
| their original owner might still be in progress.
|
| A malicious guest might be able to cause data corruption and data
| leaks. Host or guest Denial of Service (DoS), and privilege
| escalation, cannot be ruled out.
XSA-347 [3] "unsafe AMD IOMMU page table updates":
| AMD IOMMU page table entries are updated in a step by step manner,
| without regard to them being potentially in use by the IOMMU.
| Therefore it was possible that the IOMMU would read and then use a
| half-updated entry. Furthermore, updates to Device Table entries
| lacked suitable ordering enforcement for certain steps involved in
| these updates.
|
| In both case the specific outcome heavily depends on how exactly the
| compiler translated the affected pieces of code.
|
| A malicious guest might be able to cause data corruption and data
| leaks. Host or guest Denial of Service (DoS), and privilege
| escalation, cannot be ruled out.
Impact
=======
https://www.qubes-os.org/news/2020/10/20/qsb-060/
We have just published Qubes Security Bulletin (QSB) #060: Multiple Xen
issues (XSA-345, XSA-346, XSA-347). 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).
Special note: Although XSA-345 is included in this QSB, we do not
consider XSA-345 to affect the security of Qubes OS (https://www.qubes-os.org/news/2020/10/20/xsa-286-331-332-345-qubes-not-affected/),
since the default configuration is safe, and we have already implemented
appropriate safeguards to prevent users from changing to a vulnerable
configuration by accident. Please see the Impact section in QSB #060
below for further details.
View QSB #060 in the qubes-secpack:
https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-060-2020.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 the associated XSAs in the XSA Tracker:
https://www.qubes-os.org/security/xsa/#345
https://www.qubes-os.org/security/xsa/#346
https://www.qubes-os.org/security/xsa/#347
---===[ Qubes Security Bulletin #60 ]===---
2020-10-20
Multiple Xen issues (XSA-345, XSA-346, XSA-347)
Summary
========
On 2020-10-20, the Xen Security Team published the following Xen
Security Advisories (XSAs):
XSA-345 [1] "x86: Race condition in Xen mapping code":
| The Xen code handling the updating of the hypervisor's own pagetables
| tries to use 2MiB and 1GiB superpages as much as possible to maximize
| TLB efficiency. Some of the operations for checking and coalescing
| superpages take non-negligible amount of time; to avoid potential lock
| contention, this code also tries to avoid holding locks for the entire
| operation.
|
| Unfortunately, several potential race conditions were not considered;
| precisely-timed guest actions could potentially lead to the code
| writing to a page which has been freed (and thus potentially already
| reused).
|
| A malicious guest can cause a host denial-of-service. Data corruption
| or privilege escalation cannot be ruled out.
XSA-346 [2] "undue deferral of IOMMU TLB flushes":
| To efficiently change the physical to machine address mappings of a
| larger range of addresses for fully virtualized guests, Xen contains
| an optimization to coalesce per-page IOMMU TLB flushes into a single,
| wider flush after all adjustments have been made. While this is fine
| to do for newly introduced page mappings, the possible removal of
| pages from such guests during this operation should not be "optimized"
| in the same way. This is because the (typically) final reference of
| such pages is dropped before the coalesced flush, and hence the pages
| may have been put to a different use even though DMA initiated by
| their original owner might still be in progress.
|
| A malicious guest might be able to cause data corruption and data
| leaks. Host or guest Denial of Service (DoS), and privilege
| escalation, cannot be ruled out.
XSA-347 [3] "unsafe AMD IOMMU page table updates":
| AMD IOMMU page table entries are updated in a step by step manner,
| without regard to them being potentially in use by the IOMMU.
| Therefore it was possible that the IOMMU would read and then use a
| half-updated entry. Furthermore, updates to Device Table entries
| lacked suitable ordering enforcement for certain steps involved in
| these updates.
|
| In both case the specific outcome heavily depends on how exactly the
| compiler translated the affected pieces of code.
|
| A malicious guest might be able to cause data corruption and data
| leaks. Host or guest Denial of Service (DoS), and privilege
| escalation, cannot be ruled out.
Impact
=======
XSA-345: The default Qubes configuration is safe. Shadow mode for HVM
and PVH domains is disabled at build time, and domains that have PCI
devices run in HVM mode by default. Therefore, we do not consider this
XSA to affect the security of Qubes OS. However, we are including it in
this QSB anyway since it is technically possible for the user to
manually change a domain that has PCI devices from HVM to PV, which
would result in a configuration that is vulnerable to this issue. Having
anticipated the risk associated with such a manual change, we have
already implemented appropriate safeguards. In the Qubes GUI for
changing VM settings, the user would have to go to the "Advanced" tab in
order to change the setting from HVM to PV. Upon making the change, the
user would immediately be confronted with a warning in bold red text
that reads, "Using PV mode exposes more hypervisor attack surface!"
Therefore, it is nearly impossible users would switch to the vulnerable
configuration by accident.
XSA-346, XSA-457: A malicious domain with a PCI device (e.g., sys-net or
sys-usb in the default configuration) could try to exploit this
vulnerability in order to crash the host. Beyond DoS, it is unlikely
that this vulnerability could be exploited to compromise the system, but
we cannot completely rule out the possibility. Both of these issues
apply only to systems running on AMD processors.
Patching
=========
The specific packages that resolve the problems discussed in this
bulletin are as follows:
For Qubes 4.0:
- Xen packages, version 4.8.5-25
For Qubes 4.1:
- Xen packages, version 4.14.0-6
The packages are to be installed in dom0 via the Qube 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 Advisories.
References
===========
[1] https://xenbits.xen.org/xsa/advisory-345.html
[1] https://xenbits.xen.org/xsa/advisory-346.html
[1] https://xenbits.xen.org/xsa/advisory-347.html
--
The Qubes Security Team
https://www.qubes-os.org/security/
and PVH domains is disabled at build time, and domains that have PCI
devices run in HVM mode by default. Therefore, we do not consider this
XSA to affect the security of Qubes OS. However, we are including it in
this QSB anyway since it is technically possible for the user to
manually change a domain that has PCI devices from HVM to PV, which
would result in a configuration that is vulnerable to this issue. Having
anticipated the risk associated with such a manual change, we have
already implemented appropriate safeguards. In the Qubes GUI for
changing VM settings, the user would have to go to the "Advanced" tab in
order to change the setting from HVM to PV. Upon making the change, the
user would immediately be confronted with a warning in bold red text
that reads, "Using PV mode exposes more hypervisor attack surface!"
Therefore, it is nearly impossible users would switch to the vulnerable
configuration by accident.
XSA-346, XSA-457: A malicious domain with a PCI device (e.g., sys-net or
sys-usb in the default configuration) could try to exploit this
vulnerability in order to crash the host. Beyond DoS, it is unlikely
that this vulnerability could be exploited to compromise the system, but
we cannot completely rule out the possibility. Both of these issues
apply only to systems running on AMD processors.
Patching
=========
The specific packages that resolve the problems discussed in this
bulletin are as follows:
For Qubes 4.0:
- Xen packages, version 4.8.5-25
For Qubes 4.1:
- Xen packages, version 4.14.0-6
The packages are to be installed in dom0 via the Qube 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 Advisories.
References
===========
[1] https://xenbits.xen.org/xsa/advisory-345.html
[1] https://xenbits.xen.org/xsa/advisory-346.html
[1] https://xenbits.xen.org/xsa/advisory-347.html
--
The Qubes Security Team
https://www.qubes-os.org/security/
XSAs 286, 331, 332, and 345 do not affect the security of Qubes OS
https://www.qubes-os.org/news/2020/10/20/xsa-286-331-332-345-qubes-not-affected/
The Xen Project has published the following Xen Security Advisories:
XSA-286, XSA-331, XSA-332, and XSA-345. These XSAs do not affect the
security of Qubes OS, and no user action is necessary.
Special note: Although XSA-345 is included in QSB #060 (https://www.qubes-os.org/news/2020/10/20/qsb-060/), we do not
consider XSA-345 to affect the security of Qubes OS, since the default
configuration is safe, and we have already implemented appropriate
safeguards to prevent users from changing to a vulnerable configuration
by accident. Please see the Impact section of QSB #060 (https://www.qubes-os.org/news/2020/10/20/qsb-060/) for further
details.
These XSAs have been added to the XSA Tracker (https://www.qubes-os.org/security/xsa/):
https://www.qubes-os.org/security/xsa/#286
https://www.qubes-os.org/security/xsa/#331
https://www.qubes-os.org/security/xsa/#332
https://www.qubes-os.org/security/xsa/#345
https://www.qubes-os.org/news/2020/10/20/xsa-286-331-332-345-qubes-not-affected/
The Xen Project has published the following Xen Security Advisories:
XSA-286, XSA-331, XSA-332, and XSA-345. These XSAs do not affect the
security of Qubes OS, and no user action is necessary.
Special note: Although XSA-345 is included in QSB #060 (https://www.qubes-os.org/news/2020/10/20/qsb-060/), we do not
consider XSA-345 to affect the security of Qubes OS, since the default
configuration is safe, and we have already implemented appropriate
safeguards to prevent users from changing to a vulnerable configuration
by accident. Please see the Impact section of QSB #060 (https://www.qubes-os.org/news/2020/10/20/qsb-060/) for further
details.
These XSAs have been added to the XSA Tracker (https://www.qubes-os.org/security/xsa/):
https://www.qubes-os.org/security/xsa/#286
https://www.qubes-os.org/security/xsa/#331
https://www.qubes-os.org/security/xsa/#332
https://www.qubes-os.org/security/xsa/#345
Fedora 31 approaching EOL
https://www.qubes-os.org/news/2020/10/27/fedora-31-approaching-eol/
Fedora 33 was released today (https://fedoramagazine.org/announcing-fedora-33/), 2020-10-27. According to the Fedora
Release Life Cycle (https://fedoraproject.org/wiki/Fedora_Release_Life_Cycle), this means that Fedora 31 is scheduled to reach
EOL (end-of-life (https://fedoraproject.org/wiki/End_of_life)) in approximately four weeks, around 2020-11-24 (https://www.timeanddate.com/date/dateadded.html?m1=10&d1=27&y1=2020&type=add&ay=&am=&aw=4&ad=&rec=).
We strongly recommend that all Qubes users upgrade their Fedora 31
TemplateVMs and StandaloneVMs to Fedora 32 or higher before Fedora 31
reaches EOL. We provide step-by-step upgrade instructions for upgrading
Fedora TemplateVMs (https://www.qubes-os.org/doc/template/fedora/upgrade/). For a complete list of TemplateVM versions
supported for your specific version of Qubes, see Supported TemplateVM
Versions (https://www.qubes-os.org/doc/supported-versions/#templatevms).
We also provide a fresh Fedora 32 TemplateVM package through the
official Qubes repositories, which you can install in dom0 by following
the standard installation instructions (https://www.qubes-os.org/doc/templates/fedora/#installing).
After upgrading your TemplateVMs, please remember to switch all qubes
that were using the old template to use the new one (https://www.qubes-os.org/doc/templates/#switching).
Please note that no user action is required regarding the OS version in
dom0. For details, please see our note on dom0 and EOL (https://www.qubes-os.org/doc/supported-versions/#note-on-dom0-and-eol).
https://www.qubes-os.org/news/2020/10/27/fedora-31-approaching-eol/
Fedora 33 was released today (https://fedoramagazine.org/announcing-fedora-33/), 2020-10-27. According to the Fedora
Release Life Cycle (https://fedoraproject.org/wiki/Fedora_Release_Life_Cycle), this means that Fedora 31 is scheduled to reach
EOL (end-of-life (https://fedoraproject.org/wiki/End_of_life)) in approximately four weeks, around 2020-11-24 (https://www.timeanddate.com/date/dateadded.html?m1=10&d1=27&y1=2020&type=add&ay=&am=&aw=4&ad=&rec=).
We strongly recommend that all Qubes users upgrade their Fedora 31
TemplateVMs and StandaloneVMs to Fedora 32 or higher before Fedora 31
reaches EOL. We provide step-by-step upgrade instructions for upgrading
Fedora TemplateVMs (https://www.qubes-os.org/doc/template/fedora/upgrade/). For a complete list of TemplateVM versions
supported for your specific version of Qubes, see Supported TemplateVM
Versions (https://www.qubes-os.org/doc/supported-versions/#templatevms).
We also provide a fresh Fedora 32 TemplateVM package through the
official Qubes repositories, which you can install in dom0 by following
the standard installation instructions (https://www.qubes-os.org/doc/templates/fedora/#installing).
After upgrading your TemplateVMs, please remember to switch all qubes
that were using the old template to use the new one (https://www.qubes-os.org/doc/templates/#switching).
Please note that no user action is required regarding the OS version in
dom0. For details, please see our note on dom0 and EOL (https://www.qubes-os.org/doc/supported-versions/#note-on-dom0-and-eol).
Forwarded from „Peter Funk“
If you are a german speaker and want to discuss QubesOS in the german language then there is also an unofficial telegram group called „QubesOS Benutzer Deutschsprachig“ which has (as of today) ten members beside me: https://news.1rj.ru/str/QubesOS_user_de As of today the traffic volume is low.
Telegram
QubesOS Benutzer Deutschsprachig
Zum Erfahrungsaustausch über QubesOS in deutscher Sprache (Spam wird gelöscht). Achtung: Telegram Gruppen-Chats sind nur transport- und nicht Ende zu Ende verschlüsselt. FPR des Master Signing Keys: 0x427F11FD0FAA4B080123F01CDDFA1A3E36879494
Join our English support group here: https://news.1rj.ru/str/joinchat/B8FHpkEToMfgdREGV7wzRQ
Anyone is welcomed!
Note: please confirm Captcha so we know you are human. Thanks!
Anyone is welcomed!
Note: please confirm Captcha so we know you are human. Thanks!
Telegram
QubesOS Chat
(Community Support)
Alternative community instead of online forum and discord.
@QubesOS
>No spam/ads/NSFW/shit posts/spam bots
>Respect others
>Stay on topic
>Be transparent
If you need help ask!
Rules are enforced with ban or restrictions.
Alternative community instead of online forum and discord.
@QubesOS
>No spam/ads/NSFW/shit posts/spam bots
>Respect others
>Stay on topic
>Be transparent
If you need help ask!
Rules are enforced with ban or restrictions.
Xen Summit Keynote: Your self-driving car is awesome. . .because of open source software like Xen
https://xenproject.org/2020/10/30/xen-summit-keynote-your-self-driving-car-is-awesome-because-of-open-source-software-like-xen/
In this blog series, we will revisit talks from the recent Xen Project Developer and Design Summit, which took place virtually in the summer of 2020. In his keynote speech,...
https://xenproject.org/2020/10/30/xen-summit-keynote-your-self-driving-car-is-awesome-because-of-open-source-software-like-xen/
In this blog series, we will revisit talks from the recent Xen Project Developer and Design Summit, which took place virtually in the summer of 2020. In his keynote speech,...
Qubes OS 4.0.4-rc1 has been released!
https://www.qubes-os.org/news/2020/11/05/qubes-4-0-4-rc1/
We’re pleased to announce the first release candidate for Qubes OS
4.0.4.
Qubes OS 4.0.4-rc1 includes many updates over the initial 4.0 release,
in particular:
All 4.0 dom0 updates to date
Fedora 32 TemplateVM
Debian 10 TemplateVM
Whonix 15 Gateway and Workstation TemplateVMs
Linux kernel 4.19 by default
Qubes 4.0.4-rc1 is available on the downloads (https://www.qubes-os.org/downloads/) page.
What is a point release?
A point release does not designate a separate, new version of Qubes OS.
Rather, it designates its respective major or minor release (in this
case, 4.0) inclusive of all updates up to a certain point. Installing
Qubes 4.0 and fully updating it results in the same system as installing
Qubes 4.0.4.
What should I do?
If you installed Qubes 4.0, 4.0.1, 4.0.2, or 4.0.3 and have fully
updated (https://www.qubes-os.org/doc/updating-qubes-os/), then your system is already equivalent to a Qubes 4.0.4
installation. No further action is required.
Regardless of your current OS, if you wish to install (or reinstall)
Qubes 4.0 for any reason, then the 4.0.4 ISO makes this more convenient
and secure, since it bundles all Qubes 4.0 updates to date. Please see
the installation guide (https://www.qubes-os.org/doc/installation-guide/) for detailed instructions.
If you’re willing to test (https://www.qubes-os.org/doc/testing/) this release candidate, you can help to
improve the stable release by reporting any bugs you encounter (https://www.qubes-os.org/doc/reporting-bugs/).
Release candidate planning
If no major issues are discovered in 4.0.4-rc1, we expect to announce
the stable release of 4.0.4 in a couple weeks.
https://www.qubes-os.org/news/2020/11/05/qubes-4-0-4-rc1/
We’re pleased to announce the first release candidate for Qubes OS
4.0.4.
Qubes OS 4.0.4-rc1 includes many updates over the initial 4.0 release,
in particular:
All 4.0 dom0 updates to date
Fedora 32 TemplateVM
Debian 10 TemplateVM
Whonix 15 Gateway and Workstation TemplateVMs
Linux kernel 4.19 by default
Qubes 4.0.4-rc1 is available on the downloads (https://www.qubes-os.org/downloads/) page.
What is a point release?
A point release does not designate a separate, new version of Qubes OS.
Rather, it designates its respective major or minor release (in this
case, 4.0) inclusive of all updates up to a certain point. Installing
Qubes 4.0 and fully updating it results in the same system as installing
Qubes 4.0.4.
What should I do?
If you installed Qubes 4.0, 4.0.1, 4.0.2, or 4.0.3 and have fully
updated (https://www.qubes-os.org/doc/updating-qubes-os/), then your system is already equivalent to a Qubes 4.0.4
installation. No further action is required.
Regardless of your current OS, if you wish to install (or reinstall)
Qubes 4.0 for any reason, then the 4.0.4 ISO makes this more convenient
and secure, since it bundles all Qubes 4.0 updates to date. Please see
the installation guide (https://www.qubes-os.org/doc/installation-guide/) for detailed instructions.
If you’re willing to test (https://www.qubes-os.org/doc/testing/) this release candidate, you can help to
improve the stable release by reporting any bugs you encounter (https://www.qubes-os.org/doc/reporting-bugs/).
Release candidate planning
If no major issues are discovered in 4.0.4-rc1, we expect to announce
the stable release of 4.0.4 in a couple weeks.
Design Session – Xen FuSA SIG present and future
https://xenproject.org/2020/11/06/design-session-xen-fusa-sig-present-and-future/
In this Xen Summit Design Session, the Xen Functional Safety Special Interest Group (FuSA SIG), outlines the progress of the group around Xen and Certification, what is currently being done,...
https://xenproject.org/2020/11/06/design-session-xen-fusa-sig-present-and-future/
In this Xen Summit Design Session, the Xen Functional Safety Special Interest Group (FuSA SIG), outlines the progress of the group around Xen and Certification, what is currently being done,...