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,...
QSB #061: Information leak via power sidechannel (XSA-351)
https://www.qubes-os.org/news/2020/11/10/qsb-061/
We have just published Qubes Security Bulletin (QSB) #061:
Information leak via power sidechannel (XSA-351).
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 #061 in the qubes-secpack:
https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-061-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 XSA-351 in the XSA Tracker:
https://www.qubes-os.org/security/xsa/#351
---===[ Qubes Security Bulletin #61 ]===---
2020-11-10
Information leak via power sidechannel (XSA-351)
Summary
========
On 2020-11-10, the Xen Security Team published Xen Security Advisory
351 (XSA-351) [1] with the following denoscription:
| Researchers have demonstrated using software power/energy monitoring
| interfaces to create covert channels, and infer the operations/data used
| by other contexts within the system.
|
| Access to these interfaces should be restricted to privileged software,
| but it was found that Xen doesn't restrict access suitably, and the
| interfaces are accessible to all guests.
|
| For more information, see:
| https://platypusattack.com
| https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00389.html
|
| An unprivileged guest administrator can sample platform power/energy
| data. This may be used to infer the operations/data used by other
| contexts within the system.
|
| The research demonstrates using this sidechannel to leak the AES keys
| used elsewhere in the system.
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-26
For Qubes 4.1:
- Xen packages, version 4.14.0-7
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-351.html
--
The Qubes Security Team
https://www.qubes-os.org/security/
https://www.qubes-os.org/news/2020/11/10/qsb-061/
We have just published Qubes Security Bulletin (QSB) #061:
Information leak via power sidechannel (XSA-351).
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 #061 in the qubes-secpack:
https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-061-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 XSA-351 in the XSA Tracker:
https://www.qubes-os.org/security/xsa/#351
---===[ Qubes Security Bulletin #61 ]===---
2020-11-10
Information leak via power sidechannel (XSA-351)
Summary
========
On 2020-11-10, the Xen Security Team published Xen Security Advisory
351 (XSA-351) [1] with the following denoscription:
| Researchers have demonstrated using software power/energy monitoring
| interfaces to create covert channels, and infer the operations/data used
| by other contexts within the system.
|
| Access to these interfaces should be restricted to privileged software,
| but it was found that Xen doesn't restrict access suitably, and the
| interfaces are accessible to all guests.
|
| For more information, see:
| https://platypusattack.com
| https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00389.html
|
| An unprivileged guest administrator can sample platform power/energy
| data. This may be used to infer the operations/data used by other
| contexts within the system.
|
| The research demonstrates using this sidechannel to leak the AES keys
| used elsewhere in the system.
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-26
For Qubes 4.1:
- Xen packages, version 4.14.0-7
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-351.html
--
The Qubes Security Team
https://www.qubes-os.org/security/
QSB #062: Stack corruption from XSA-346 change (XSA-355)
https://www.qubes-os.org/news/2020/11/24/qsb-062/
We have just published Qubes Security Bulletin (QSB) #062:
Stack corruption from XSA-346 change (XSA-355).
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 #062 in the qubes-secpack:
https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-062-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 XSA-355 in the XSA Tracker:
https://www.qubes-os.org/security/xsa/#355
---===[ Qubes Security Bulletin #62 ]===---
2020-11-24
Stack corruption from XSA-346 change (XSA-355)
Summary
========
On 2020-11-24, the Xen Security Team published Xen Security Advisory
355 (XSA-355) [1] with the following denoscription:
| One of the two changes for XSA-346 introduced an on-stack array. The
| check for guarding against overrunning this array was off by one,
| allowing for corruption of the first stack slot immediately following
| this array.
|
| A malicious or buggy HVM or PVH guest can cause Xen to crash, resulting
| in a Denial of Service (DoS) to the entire host. Privilege escalation
| as well as information leaks cannot be excluded.
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-27
For Qubes 4.1:
- Xen packages, version 4.14.0-8
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-355.html
--
The Qubes Security Team
https://www.qubes-os.org/security/
https://www.qubes-os.org/news/2020/11/24/qsb-062/
We have just published Qubes Security Bulletin (QSB) #062:
Stack corruption from XSA-346 change (XSA-355).
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 #062 in the qubes-secpack:
https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-062-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 XSA-355 in the XSA Tracker:
https://www.qubes-os.org/security/xsa/#355
---===[ Qubes Security Bulletin #62 ]===---
2020-11-24
Stack corruption from XSA-346 change (XSA-355)
Summary
========
On 2020-11-24, the Xen Security Team published Xen Security Advisory
355 (XSA-355) [1] with the following denoscription:
| One of the two changes for XSA-346 introduced an on-stack array. The
| check for guarding against overrunning this array was off by one,
| allowing for corruption of the first stack slot immediately following
| this array.
|
| A malicious or buggy HVM or PVH guest can cause Xen to crash, resulting
| in a Denial of Service (DoS) to the entire host. Privilege escalation
| as well as information leaks cannot be excluded.
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-27
For Qubes 4.1:
- Xen packages, version 4.14.0-8
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-355.html
--
The Qubes Security Team
https://www.qubes-os.org/security/
Qubes Survey: The Results
https://www.qubes-os.org/news/2020/11/26/qubes-survey-results/
Hello, lovely Qubes Community!
A couple of weeks ago, we asked you to participate in a survey; to our delight and surprise, over 2100 of you decided to help us and filled it out!
We are grateful for our wonderful community and wanted to share some interesting findings from the survey with you.
A small statistical note: a survey such as this, on a non-random and very much self-selected sample, is not necessarily completely representative of the whole community.
It’s quite possible that the people whom we did not reach and the people who decided not the participate in the survey differ in statistical ways from those we did survey, so please understand all of the “community members say X” statements below as having a little asterisk with “as far as we know based on this survey”.
Some introductory stats: 54% percent of our respondents have Qubes installed, and 22% are planning to.
https://www.qubes-os.org/news/2020/11/26/qubes-survey-results/
Hello, lovely Qubes Community!
A couple of weeks ago, we asked you to participate in a survey; to our delight and surprise, over 2100 of you decided to help us and filled it out!
We are grateful for our wonderful community and wanted to share some interesting findings from the survey with you.
A small statistical note: a survey such as this, on a non-random and very much self-selected sample, is not necessarily completely representative of the whole community.
It’s quite possible that the people whom we did not reach and the people who decided not the participate in the survey differ in statistical ways from those we did survey, so please understand all of the “community members say X” statements below as having a little asterisk with “as far as we know based on this survey”.
Some introductory stats: 54% percent of our respondents have Qubes installed, and 22% are planning to.