Comment on Summer = Xen Project Internships! by zkeaton
https://blog.xenproject.org/2018/04/26/summer-xen-project-internships/#comment-500
That's great to hear! Please look to applying for next year. Currently the internships are closed for this year.
https://blog.xenproject.org/2018/04/26/summer-xen-project-internships/#comment-500
That's great to hear! Please look to applying for next year. Currently the internships are closed for this year.
Xen Project Announces Schedule for its Annual Developer and Design Summit
https://blog.xenproject.org/2018/05/03/xen-project-announces-schedule-for-its-annual-developer-and-design-summi/
Today, we are excited to announce the program and speakers for the Xen Project Developer and Design Summit. The summit brings together developers, engineers, and Xen Project power users for in-person collaboration and educational presentations. The event will take place in Nanjing Jiangning, China from June 20 -22, 2018. This is the fifth annual Xen […]
https://blog.xenproject.org/2018/05/03/xen-project-announces-schedule-for-its-annual-developer-and-design-summi/
Today, we are excited to announce the program and speakers for the Xen Project Developer and Design Summit. The summit brings together developers, engineers, and Xen Project power users for in-person collaboration and educational presentations. The event will take place in Nanjing Jiangning, China from June 20 -22, 2018. This is the fifth annual Xen […]
QSB #39: Xen vulnerability (XSA-260) and GUI daemon issue
https://www.qubes-os.org/news/2018/05/08/qsb-39/
Dear Qubes Community,
We have just published Qubes Security Bulletin (QSB) #39:
Xen vulnerability (XSA-260) and GUI daemon issue.
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 #39 in the qubes-secpack:
https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-039-2018.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/
---===[ Qubes Security Bulletin #39 ]===---
May 8, 2018
Xen vulnerability (XSA-260) and GUI daemon issue
Summary
========
Today, the Xen Security Team released Xen Security Advisories 260
through 262. Among these, only XSA-260 affects the security of Qubes
OS. The bug described in XSA-260 allows an attacker controlling a PV
domain to break out to dom0. This is a critical bug for Qubes 3.2, but
for Qubes 4.0 is much less severe, since all the domains that run
untrusted code in Qubes 4.0 are either PVH or HVM by default.
Additionally, Christoffer Kugg Jerkeby discovered a situation in which
Qubes GUI virtualization could allow a VM to produce a window with
borders that are white instead of the color of the VM's label. (In
Qubes, border colors are used as front-line indicators of trust.)
However, a VM cannot use this vulnerability to draw borders with a
non-white color other than the correct one. A very similar bug was
fixed as part of QSB #34 [1], but the fix missed this one case, as
described below.
Technical details
==================
Xen issues
-----------
Xen Security Advisory 260 [2]:
| When switching stacks, it is critical to have a matching stack segment
| and stack pointer. To allow an atomic update from what would otherwise
| be two adjacent instructions, an update which changes the stack segment
| (either a mov or pop instruction with %ss encoded as the destination
| register) sets the movss shadow for one instruction.
|
| The exact behaviour of the movss shadow is poorly understood.
|
| In practice, a movss shadow delays some debug exceptions (e.g. from a
| hardware breakpoint) until the subsequent instruction has completed. If
| the subsequent instruction normally transitions to supervisor mode
| (e.g. a system call), then the debug exception will be taken after the
| transition to ring0 is completed.
|
| For most transitions to supervisor mode, this only confuses Xen into
| printing a lot of debugging information. For the syscall instruction
| however, the exception gets taken before the syscall handler can move
| off the guest stack.
|
| A malicious PV guest can escalate their privilege to that of the
| hypervisor.
GUI daemon issue
----------------
In QSB #34, we reported a similar bug involving the Qubes GUI daemon.
Whenever a VM displays a borderless window in Qubes, the GUI daemon is
responsible for drawing a colored border around it. In particular,
whenever a window content update is sent for the border area of a
borderless window, the GUI daemon is supposed to draw a 2px border in
that location.
The bug reported in QSB #34 occurred when a VM showed a borderless
splash screen window with a custom shape. While custom window shapes are
not supported in Qubes OS, VMs do not know this. The VM still thought
the custom-shaped window was there, so it never sent window content
updates outside of the custom shape. Hence, it never sent window content
updates for the border areas of custom-shaped windows. Since there were
no window content updates for the border areas, the GUI daemon failed to
recognize that it should draw colored borders in those locations. As a
result, custom-shaped splash screen windows had no borders at all. From
https://www.qubes-os.org/news/2018/05/08/qsb-39/
Dear Qubes Community,
We have just published Qubes Security Bulletin (QSB) #39:
Xen vulnerability (XSA-260) and GUI daemon issue.
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 #39 in the qubes-secpack:
https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-039-2018.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/
---===[ Qubes Security Bulletin #39 ]===---
May 8, 2018
Xen vulnerability (XSA-260) and GUI daemon issue
Summary
========
Today, the Xen Security Team released Xen Security Advisories 260
through 262. Among these, only XSA-260 affects the security of Qubes
OS. The bug described in XSA-260 allows an attacker controlling a PV
domain to break out to dom0. This is a critical bug for Qubes 3.2, but
for Qubes 4.0 is much less severe, since all the domains that run
untrusted code in Qubes 4.0 are either PVH or HVM by default.
Additionally, Christoffer Kugg Jerkeby discovered a situation in which
Qubes GUI virtualization could allow a VM to produce a window with
borders that are white instead of the color of the VM's label. (In
Qubes, border colors are used as front-line indicators of trust.)
However, a VM cannot use this vulnerability to draw borders with a
non-white color other than the correct one. A very similar bug was
fixed as part of QSB #34 [1], but the fix missed this one case, as
described below.
Technical details
==================
Xen issues
-----------
Xen Security Advisory 260 [2]:
| When switching stacks, it is critical to have a matching stack segment
| and stack pointer. To allow an atomic update from what would otherwise
| be two adjacent instructions, an update which changes the stack segment
| (either a mov or pop instruction with %ss encoded as the destination
| register) sets the movss shadow for one instruction.
|
| The exact behaviour of the movss shadow is poorly understood.
|
| In practice, a movss shadow delays some debug exceptions (e.g. from a
| hardware breakpoint) until the subsequent instruction has completed. If
| the subsequent instruction normally transitions to supervisor mode
| (e.g. a system call), then the debug exception will be taken after the
| transition to ring0 is completed.
|
| For most transitions to supervisor mode, this only confuses Xen into
| printing a lot of debugging information. For the syscall instruction
| however, the exception gets taken before the syscall handler can move
| off the guest stack.
|
| A malicious PV guest can escalate their privilege to that of the
| hypervisor.
GUI daemon issue
----------------
In QSB #34, we reported a similar bug involving the Qubes GUI daemon.
Whenever a VM displays a borderless window in Qubes, the GUI daemon is
responsible for drawing a colored border around it. In particular,
whenever a window content update is sent for the border area of a
borderless window, the GUI daemon is supposed to draw a 2px border in
that location.
The bug reported in QSB #34 occurred when a VM showed a borderless
splash screen window with a custom shape. While custom window shapes are
not supported in Qubes OS, VMs do not know this. The VM still thought
the custom-shaped window was there, so it never sent window content
updates outside of the custom shape. Hence, it never sent window content
updates for the border areas of custom-shaped windows. Since there were
no window content updates for the border areas, the GUI daemon failed to
recognize that it should draw colored borders in those locations. As a
result, custom-shaped splash screen windows had no borders at all. From
the GUI daemon's perspective, all VMs are untrusted insofar as they
cannot be relied upon to cooperate in drawing the correct colored
borders around their windows. Therefore, the blame for this bug lies
solely with the GUI daemon, not with the VM that failed to send window
content updates.
While the patch for QSB #34 fixed the case just described, it failed to
fix the case in which no window image is sent at all before mapping the
window. In this latter case, the argument sanitization section of the
do_shm_update function is skipped, resulting in arguments being ignored.
This, in turn, results in the entire window, including its borders,
appearing as a solid white rectangle on the screen.
Patching
=========
The specific packages that resolve the problems discussed in this
bulletin are as follows:
For Qubes 3.2:
- Xen packages, version 4.6.6-40
- qubes-gui-dom0, version 3.2.13
For Qubes 4.0:
- Xen packages, version 4.8.2-7
- qubes-gui-dom0, version 4.0.8
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
========
The GUI issue was discovered by Christoffer Kugg Jerkeby.
For other issues, see the original Xen Security Advisories.
References
===========
[1] https://www.qubes-os.org/news/2017/10/12/qsb-34/
[2] https://xenbits.xen.org/xsa/advisory-260.html
--
The Qubes Security Team
https://www.qubes-os.org/security/
cannot be relied upon to cooperate in drawing the correct colored
borders around their windows. Therefore, the blame for this bug lies
solely with the GUI daemon, not with the VM that failed to send window
content updates.
While the patch for QSB #34 fixed the case just described, it failed to
fix the case in which no window image is sent at all before mapping the
window. In this latter case, the argument sanitization section of the
do_shm_update function is skipped, resulting in arguments being ignored.
This, in turn, results in the entire window, including its borders,
appearing as a solid white rectangle on the screen.
Patching
=========
The specific packages that resolve the problems discussed in this
bulletin are as follows:
For Qubes 3.2:
- Xen packages, version 4.6.6-40
- qubes-gui-dom0, version 3.2.13
For Qubes 4.0:
- Xen packages, version 4.8.2-7
- qubes-gui-dom0, version 4.0.8
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
========
The GUI issue was discovered by Christoffer Kugg Jerkeby.
For other issues, see the original Xen Security Advisories.
References
===========
[1] https://www.qubes-os.org/news/2017/10/12/qsb-34/
[2] https://xenbits.xen.org/xsa/advisory-260.html
--
The Qubes Security Team
https://www.qubes-os.org/security/
Fedora 26 and Debian 8 approaching EOL
https://www.qubes-os.org/news/2018/05/23/fedora-26-and-debian-8-approaching-eol/
Fedora 26 will reach EOL (end-of-life (https://fedoraproject.org/wiki/Fedora_Release_Life_Cycle#Maintenance_Schedule)) on 2018-06-01, and Debian 8
(“Jessie” full, not LTS (https://wiki.debian.org/DebianReleases)) will reach EOL on
2018-06-06. We strongly recommend that all Qubes users upgrade their
Fedora 26 and Debian 8 TemplateVMs and StandaloneVMs to Fedora 27 and
Debian 9 or higher, respectively, by these EOL dates. We provide
step-by-step upgrade instructions for upgrading from Fedora 26 to 27 (https://www.qubes-os.org/doc/template/fedora/upgrade-26-to-27/),
Fedora 27 to 28 (https://www.qubes-os.org/doc/template/fedora/upgrade-27-to-28/), and Debian 8 to 9 (https://www.qubes-os.org/doc/template/debian/upgrade-8-to-9/). 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 fresh Fedora 27, Fedora 28, and Debian 9 TemplateVM
packages through the official Qubes repositories, which you can install
in dom0 by following the standard installation instructions for Fedora (https://www.qubes-os.org/doc/templates/fedora/#installing)
and Debian (https://www.qubes-os.org/doc/templates/debian/#installing) TemplateVMs.
After upgrading your TemplateVMs, please remember to set all qubes that
were using the old template to use the new one. The instructions to do
this can be found in the upgrade instructions for Fedora 26 to 27 (https://www.qubes-os.org/doc/template/fedora/upgrade-26-to-27/),
Fedora 27 to 28 (https://www.qubes-os.org/doc/template/fedora/upgrade-27-to-28/), and Debian 8 to 9 (https://www.qubes-os.org/doc/template/debian/upgrade-8-to-9/).
Please note that no user action is required regarding the OS version in
dom0. If you’re using Qubes 3.2 or 4.0, there is no dom0 OS upgrade
available, since none is currently required. For details, please see our
Note on dom0 and EOL (https://www.qubes-os.org/doc/supported-versions/#note-on-dom0-and-eol).
If you’re using an older version of Qubes than 3.2, we strongly
recommend that you upgrade to 3.2, as older versions are no longer
supported.
https://www.qubes-os.org/news/2018/05/23/fedora-26-and-debian-8-approaching-eol/
Fedora 26 will reach EOL (end-of-life (https://fedoraproject.org/wiki/Fedora_Release_Life_Cycle#Maintenance_Schedule)) on 2018-06-01, and Debian 8
(“Jessie” full, not LTS (https://wiki.debian.org/DebianReleases)) will reach EOL on
2018-06-06. We strongly recommend that all Qubes users upgrade their
Fedora 26 and Debian 8 TemplateVMs and StandaloneVMs to Fedora 27 and
Debian 9 or higher, respectively, by these EOL dates. We provide
step-by-step upgrade instructions for upgrading from Fedora 26 to 27 (https://www.qubes-os.org/doc/template/fedora/upgrade-26-to-27/),
Fedora 27 to 28 (https://www.qubes-os.org/doc/template/fedora/upgrade-27-to-28/), and Debian 8 to 9 (https://www.qubes-os.org/doc/template/debian/upgrade-8-to-9/). 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 fresh Fedora 27, Fedora 28, and Debian 9 TemplateVM
packages through the official Qubes repositories, which you can install
in dom0 by following the standard installation instructions for Fedora (https://www.qubes-os.org/doc/templates/fedora/#installing)
and Debian (https://www.qubes-os.org/doc/templates/debian/#installing) TemplateVMs.
After upgrading your TemplateVMs, please remember to set all qubes that
were using the old template to use the new one. The instructions to do
this can be found in the upgrade instructions for Fedora 26 to 27 (https://www.qubes-os.org/doc/template/fedora/upgrade-26-to-27/),
Fedora 27 to 28 (https://www.qubes-os.org/doc/template/fedora/upgrade-27-to-28/), and Debian 8 to 9 (https://www.qubes-os.org/doc/template/debian/upgrade-8-to-9/).
Please note that no user action is required regarding the OS version in
dom0. If you’re using Qubes 3.2 or 4.0, there is no dom0 OS upgrade
available, since none is currently required. For details, please see our
Note on dom0 and EOL (https://www.qubes-os.org/doc/supported-versions/#note-on-dom0-and-eol).
If you’re using an older version of Qubes than 3.2, we strongly
recommend that you upgrade to 3.2, as older versions are no longer
supported.
Partnering with the Freedom of the Press Foundation
https://www.qubes-os.org/news/2018/05/24/partnering-with-the-freedom-of-the-press-foundation/
We’re pleased to announce that the Freedom of the Press Foundation
(FPF) (https://freedom.press/) has become a Qubes Partner (https://www.qubes-os.org/partners/#freedom-of-the-press-foundation). We look forward to continuing to
work with the FPF on an integrated SecureDrop Workstation (https://github.com/freedomofpress/securedrop-workstation) based on
Qubes OS. For more about what this collaboration entails and our next
steps together, please see today’s announcement on the SecureDrop
blog (https://securedrop.org/news/road-towards-integrated-securedrop-workstation/).
https://www.qubes-os.org/news/2018/05/24/partnering-with-the-freedom-of-the-press-foundation/
We’re pleased to announce that the Freedom of the Press Foundation
(FPF) (https://freedom.press/) has become a Qubes Partner (https://www.qubes-os.org/partners/#freedom-of-the-press-foundation). We look forward to continuing to
work with the FPF on an integrated SecureDrop Workstation (https://github.com/freedomofpress/securedrop-workstation) based on
Qubes OS. For more about what this collaboration entails and our next
steps together, please see today’s announcement on the SecureDrop
blog (https://securedrop.org/news/road-towards-integrated-securedrop-workstation/).
QSB #40: Information leaks due to processor speculative store bypass (XSA-263)
https://www.qubes-os.org/news/2018/05/24/qsb-40/
Dear Qubes Community,
We have just published Qubes Security Bulletin (QSB) #40: Information
leaks due to processor speculative store bypass (XSA-263). 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 #40 in the qubes-secpack:
https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-040-2018.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-263 in the XSA Tracker:
https://www.qubes-os.org/security/xsa/#263
---===[ Qubes Security Bulletin #40 ]===---
2018-05-24
Information leaks due to processor speculative store bypass (XSA-263)
Summary
========
On 2018-05-21, the Xen Security Team published Xen Security Advisory
263 (CVE-2018-3639 / XSA-263) [1] with the following denoscription:
| Contemporary high performance processors may use a technique commonly
| known as Memory Disambiguation, whereby speculative execution may
| proceed past unresolved stores. This opens a speculative sidechannel
| in which loads from an address which have had a recent store can
| observe and operate on the older, stale, value.
Please note that this issue was neither predisclosed nor embargoed.
Consequently, the Qubes Security Team has not had time to analyze it in
advance of issuing this bulletin.
Impact
=======
According to XSA-263, the impact of this issue is as follows:
| An attacker who can locate or create a suitable code gadget in a
| different privilege context may be able to infer the content of
| arbitrary memory accessible to that other privilege context.
|
| At the time of writing, there are no known vulnerable gadgets in the
| compiled hypervisor code. Xen has no interfaces which allow JIT code
| to be provided. Therefore we believe that the hypervisor itself is
| not vulnerable. Additionally, we do not think there is a viable
| information leak by one Xen guest against another non-cooperating
| guest.
|
| However, in most configurations, within-guest information leak is
| possible. Mitigation for this generally depends on guest changes
| (for which you must consult your OS vendor) *and* on hypervisor
| support, provided in this advisory.
In light of this, XSA-263 appears to be less severe than the related
Spectre and Meltdown vulnerabilities we discussed in QSB #37 [2].
Patching
=========
The specific packages that resolve the problems discussed in this
bulletin are as follows:
For Qubes 3.2:
- Xen packages, version 4.6.6-41
For Qubes 4.0:
- Xen packages, version 4.8.3-8
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.
In addition, Intel Corporation has announced that microcode updates
will be available soon [3]:
| Variant 3a is mitigated in the same processor microcode updates as
| Variant 4, and Intel has released these updates in beta form to OEM
| system manufacturers and system software vendors. They are being
| readied for production release, and will be delivered to consumers
| and IT Professionals in the coming weeks.
https://www.qubes-os.org/news/2018/05/24/qsb-40/
Dear Qubes Community,
We have just published Qubes Security Bulletin (QSB) #40: Information
leaks due to processor speculative store bypass (XSA-263). 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 #40 in the qubes-secpack:
https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-040-2018.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-263 in the XSA Tracker:
https://www.qubes-os.org/security/xsa/#263
---===[ Qubes Security Bulletin #40 ]===---
2018-05-24
Information leaks due to processor speculative store bypass (XSA-263)
Summary
========
On 2018-05-21, the Xen Security Team published Xen Security Advisory
263 (CVE-2018-3639 / XSA-263) [1] with the following denoscription:
| Contemporary high performance processors may use a technique commonly
| known as Memory Disambiguation, whereby speculative execution may
| proceed past unresolved stores. This opens a speculative sidechannel
| in which loads from an address which have had a recent store can
| observe and operate on the older, stale, value.
Please note that this issue was neither predisclosed nor embargoed.
Consequently, the Qubes Security Team has not had time to analyze it in
advance of issuing this bulletin.
Impact
=======
According to XSA-263, the impact of this issue is as follows:
| An attacker who can locate or create a suitable code gadget in a
| different privilege context may be able to infer the content of
| arbitrary memory accessible to that other privilege context.
|
| At the time of writing, there are no known vulnerable gadgets in the
| compiled hypervisor code. Xen has no interfaces which allow JIT code
| to be provided. Therefore we believe that the hypervisor itself is
| not vulnerable. Additionally, we do not think there is a viable
| information leak by one Xen guest against another non-cooperating
| guest.
|
| However, in most configurations, within-guest information leak is
| possible. Mitigation for this generally depends on guest changes
| (for which you must consult your OS vendor) *and* on hypervisor
| support, provided in this advisory.
In light of this, XSA-263 appears to be less severe than the related
Spectre and Meltdown vulnerabilities we discussed in QSB #37 [2].
Patching
=========
The specific packages that resolve the problems discussed in this
bulletin are as follows:
For Qubes 3.2:
- Xen packages, version 4.6.6-41
For Qubes 4.0:
- Xen packages, version 4.8.3-8
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.
In addition, Intel Corporation has announced that microcode updates
will be available soon [3]:
| Variant 3a is mitigated in the same processor microcode updates as
| Variant 4, and Intel has released these updates in beta form to OEM
| system manufacturers and system software vendors. They are being
| readied for production release, and will be delivered to consumers
| and IT Professionals in the coming weeks.
This bulletin will be updated once the Intel microcode updates are
available. No microcode update is necessary for AMD processors.
Credits
========
See the original Xen Security Advisory.
References
===========
[1] https://xenbits.xen.org/xsa/advisory-263.html
[2] https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-037-2018.txt
[3] https://www.intel.com/content/www/us/en/architecture-and-technology/facts-about-side-channel-analysis-and-intel-products.html
--
The Qubes Security Team
https://www.qubes-os.org/security/
available. No microcode update is necessary for AMD processors.
Credits
========
See the original Xen Security Advisory.
References
===========
[1] https://xenbits.xen.org/xsa/advisory-263.html
[2] https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-037-2018.txt
[3] https://www.intel.com/content/www/us/en/architecture-and-technology/facts-about-side-channel-analysis-and-intel-products.html
--
The Qubes Security Team
https://www.qubes-os.org/security/
Comment on Xen Project 4.10.1 Available by GeorgeBray_1986
https://blog.xenproject.org/2018/05/03/xen-project-4-10-1-available/#comment-512
Thank you for update! A lot of bug was fixed.
https://blog.xenproject.org/2018/05/03/xen-project-4-10-1-available/#comment-512
Thank you for update! A lot of bug was fixed.
Comment on Xen Project Announces Schedule for its Annual Developer and Design Summit by GeorgeBray_1986
https://blog.xenproject.org/2018/05/03/xen-project-announces-schedule-for-its-annual-developer-and-design-summi/#comment-511
Nice event! Good luck!
https://blog.xenproject.org/2018/05/03/xen-project-announces-schedule-for-its-annual-developer-and-design-summi/#comment-511
Nice event! Good luck!
Comment on Xen Project 4.10.1 Available by fbifido
https://blog.xenproject.org/2018/05/03/xen-project-4-10-1-available/#comment-515
Where do I see what's new, what's fix?
https://blog.xenproject.org/2018/05/03/xen-project-4-10-1-available/#comment-515
Where do I see what's new, what's fix?
Update for QSB #40: Information leaks due to processor speculative store bypass (XSA-263)
https://www.qubes-os.org/news/2018/06/13/qsb-40-update/
Dear Qubes Community,
We have updated Qubes Security Bulletin (QSB) #40: Information leaks due
to processor speculative store bypass (XSA-263). The text of the main
changes are reproduced below. For the full text, please see the complete
QSB in the qubes-secpack:
View QSB #40 in the qubes-secpack:
https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-040-2018.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-263 in the XSA Tracker:
https://www.qubes-os.org/security/xsa/#263
Changelog
==========
2018-05-24: Original QSB published
2018-06-11: Updated and clarified Patching section
Patching
=========
The mitigation for this issue is called called "Speculative Store Bypass
Disable" (SSBD). For Intel processors, SSBD requires both a software
update and a CPU microcode update. For AMD processors, a software update
alone is sufficient; no microcode update is necessary. The packages
described below provide the necessary software updates for SSBD. On
2018-05-23, Intel Corporation announced that microcode updates would be
available soon [3]:
| Variant 3a is mitigated in the same processor microcode updates as
| Variant 4, and Intel has released these updates in beta form to OEM
| system manufacturers and system software vendors. They are being
| readied for production release, and will be delivered to consumers
| and IT Professionals in the coming weeks.
However, as of 2018-06-11, we are not aware of any available microcode
updates that address this issue for Intel processors. This bulletin will
be updated once the Intel microcode updates are available.
There are several important things to note about SSBD:
1. On both Intel and AMD processors, SSBD is globally disabled by
default. If the user wishes to enable SSBD globally, the user must do
so manually with the Xen boot option `spec-ctrl=ssbd=true`. However,
enabling this option carries a performance penalty.
2. We concur with the analysis in XSA-263 that this vulnerability
presents minimal risk to Xen itself and minimal risk of inter-guest
attacks. Therefore, we believe that proper compartmentalization is
sufficient for Qubes users to mitigate this issue without having to
enable SSBD globally.
3. For Intel (but not AMD) processors, SSBD can be enabled locally by
Xen guests without the user having to manually enable it globally.
4. For AMD (but not Intel) processors, SSBD cannot be enabled locally by
Xen guests. The user must manually enable it globally for it to have
any effect at all.
5. The guest kernel determines whether SSBD is automatically enabled for
guests on systems with Intel processors. As of 2018-06-11, the
kernels we currently offer in our repositories do not enable SSBD.
https://www.qubes-os.org/news/2018/06/13/qsb-40-update/
Dear Qubes Community,
We have updated Qubes Security Bulletin (QSB) #40: Information leaks due
to processor speculative store bypass (XSA-263). The text of the main
changes are reproduced below. For the full text, please see the complete
QSB in the qubes-secpack:
View QSB #40 in the qubes-secpack:
https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-040-2018.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-263 in the XSA Tracker:
https://www.qubes-os.org/security/xsa/#263
Changelog
==========
2018-05-24: Original QSB published
2018-06-11: Updated and clarified Patching section
Patching
=========
The mitigation for this issue is called called "Speculative Store Bypass
Disable" (SSBD). For Intel processors, SSBD requires both a software
update and a CPU microcode update. For AMD processors, a software update
alone is sufficient; no microcode update is necessary. The packages
described below provide the necessary software updates for SSBD. On
2018-05-23, Intel Corporation announced that microcode updates would be
available soon [3]:
| Variant 3a is mitigated in the same processor microcode updates as
| Variant 4, and Intel has released these updates in beta form to OEM
| system manufacturers and system software vendors. They are being
| readied for production release, and will be delivered to consumers
| and IT Professionals in the coming weeks.
However, as of 2018-06-11, we are not aware of any available microcode
updates that address this issue for Intel processors. This bulletin will
be updated once the Intel microcode updates are available.
There are several important things to note about SSBD:
1. On both Intel and AMD processors, SSBD is globally disabled by
default. If the user wishes to enable SSBD globally, the user must do
so manually with the Xen boot option `spec-ctrl=ssbd=true`. However,
enabling this option carries a performance penalty.
2. We concur with the analysis in XSA-263 that this vulnerability
presents minimal risk to Xen itself and minimal risk of inter-guest
attacks. Therefore, we believe that proper compartmentalization is
sufficient for Qubes users to mitigate this issue without having to
enable SSBD globally.
3. For Intel (but not AMD) processors, SSBD can be enabled locally by
Xen guests without the user having to manually enable it globally.
4. For AMD (but not Intel) processors, SSBD cannot be enabled locally by
Xen guests. The user must manually enable it globally for it to have
any effect at all.
5. The guest kernel determines whether SSBD is automatically enabled for
guests on systems with Intel processors. As of 2018-06-11, the
kernels we currently offer in our repositories do not enable SSBD.
QSB #41: Speculative register leakage from lazy FPU context switching (XSA-267)
https://www.qubes-os.org/news/2018/06/13/qsb-41/
Dear Qubes Community,
We have just published Qubes Security Bulletin (QSB) #41: Speculative
register leakage from lazy FPU context switching (XSA-267). 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 #41 in the qubes-secpack:
https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-041-2018.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-267 in the XSA Tracker:
https://www.qubes-os.org/security/xsa/#267
---===[ Qubes Security Bulletin #41 ]===---
2018-06-13
Speculative register leakage from lazy FPU context switching (XSA-267)
Summary
========
On 2018-06-13, the Xen Security Team published Xen Security Advisory
267 (CVE-2018-3665 / XSA-267) [1] with the following denoscription:
| x86 has a hardware mechanism for lazy FPU context switching. On a
| task switch, %cr0.ts (Task Switched) gets set, and the next
| instruction to touch floating point state raises an #NM (No Math,
| later known as Device Not Available) exception.
|
| Traditionally, FPU state has been large in comparison to available
| bandwidth (and therefore slow to switch) and not used as frequently as
| cpu tasks tend to switch. This mechanism allows the OS to only switch
| FPU when necessary, which in turn increases performance.
|
| Some CPUs however speculate past an #NM exception, allowing register
| content to be leaked by a side-channel.
|
| An attacker can read x87/MMX/SSE/AVX/AVX-512 register state belonging
| to another vCPU previously scheduled on the same processor. This can
| be state belonging a different guest, or state belonging to a
| different thread inside the same guest.
This is yet another CPU hardware bug related to speculative execution.
Patching
=========
To resolve this issue, the Xen Project has provided patches disabling
lazy FPU context switching on affected systems.
The specific packages that resolve the problems discussed in this
bulletin are as follows:
For Qubes 3.2:
- Xen packages, version 4.6.6-42
For Qubes 4.0:
- Xen packages, version 4.8.3-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-267.html
--
The Qubes Security Team
https://www.qubes-os.org/security/
https://www.qubes-os.org/news/2018/06/13/qsb-41/
Dear Qubes Community,
We have just published Qubes Security Bulletin (QSB) #41: Speculative
register leakage from lazy FPU context switching (XSA-267). 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 #41 in the qubes-secpack:
https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-041-2018.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-267 in the XSA Tracker:
https://www.qubes-os.org/security/xsa/#267
---===[ Qubes Security Bulletin #41 ]===---
2018-06-13
Speculative register leakage from lazy FPU context switching (XSA-267)
Summary
========
On 2018-06-13, the Xen Security Team published Xen Security Advisory
267 (CVE-2018-3665 / XSA-267) [1] with the following denoscription:
| x86 has a hardware mechanism for lazy FPU context switching. On a
| task switch, %cr0.ts (Task Switched) gets set, and the next
| instruction to touch floating point state raises an #NM (No Math,
| later known as Device Not Available) exception.
|
| Traditionally, FPU state has been large in comparison to available
| bandwidth (and therefore slow to switch) and not used as frequently as
| cpu tasks tend to switch. This mechanism allows the OS to only switch
| FPU when necessary, which in turn increases performance.
|
| Some CPUs however speculate past an #NM exception, allowing register
| content to be leaked by a side-channel.
|
| An attacker can read x87/MMX/SSE/AVX/AVX-512 register state belonging
| to another vCPU previously scheduled on the same processor. This can
| be state belonging a different guest, or state belonging to a
| different thread inside the same guest.
This is yet another CPU hardware bug related to speculative execution.
Patching
=========
To resolve this issue, the Xen Project has provided patches disabling
lazy FPU context switching on affected systems.
The specific packages that resolve the problems discussed in this
bulletin are as follows:
For Qubes 3.2:
- Xen packages, version 4.6.6-42
For Qubes 4.0:
- Xen packages, version 4.8.3-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-267.html
--
The Qubes Security Team
https://www.qubes-os.org/security/
Qubes Canary #16
https://www.qubes-os.org/news/2018/06/14/canary-16/
Dear Qubes Community,
We have published Qubes Canary #16. The text of this canary is
reproduced below. This canary and its accompanying signatures will
always be available in the Qubes Security Pack (qubes-secpack).
View Qubes Canary #16 in the qubes-secpack:
https://github.com/QubesOS/qubes-secpack/blob/master/canaries/canary-016-2018.txt
Learn about the qubes-secpack, including how to obtain, verify, and read
it:
https://www.qubes-os.org/security/pack/
View all past canaries:
https://www.qubes-os.org/security/canaries/
---===[ Qubes Canary #16 ]===---
Statements
-----------
The Qubes core developers who have digitally signed this file [1]
state the following:
1. The date of issue of this canary is June 14, 2018.
2. There have been 41 Qubes Security Bulletins published so far.
3. The Qubes Master Signing Key fingerprint is:
427F 11FD 0FAA 4B08 0123 F01C DDFA 1A3E 3687 9494
4. No warrants have ever been served to us with regard to the Qubes OS
Project (e.g. to hand out the private signing keys or to introduce
backdoors).
5. We plan to publish the next of these canary statements in the first
two weeks of October 2018. Special note should be taken if no new canary
is published by that time or if the list of statements changes without
plausible explanation.
Special announcements
----------------------
None.
Disclaimers and notes
----------------------
We would like to remind you that Qubes OS has been designed under the
assumption that all relevant infrastructure is permanently
compromised. This means that we assume NO trust in any of the servers
or services which host or provide any Qubes-related data, in
particular, software updates, source code repositories, and Qubes ISO
downloads.
This canary scheme is not infallible. Although signing the declaration
makes it very difficult for a third party to produce arbitrary
declarations, it does not prevent them from using force or other
means, like blackmail or compromising the signers' laptops, to coerce
us to produce false declarations.
The news feeds quoted below (Proof of freshness) serves to demonstrate
that this canary could not have been created prior to the date stated.
It shows that a series of canaries was not created in advance.
This declaration is merely a best effort and is provided without any
guarantee or warranty. It is not legally binding in any way to
anybody. None of the signers should be ever held legally responsible
for any of the statements made here.
Proof of freshness
-------------------
$ date -R -u
Thu, 14 Jun 2018 07:47:57 +0000
$ feedstail -1 -n5 -f '{noscript}' -u https://www.spiegel.de/international/index.rss
Rise of the Autocrats: Liberal Democracy Is Under Attack
Economic Trumpism: U.S. President Makes Life Tough for German Companies
The G-7 Fiasco: It's Time to Isolate Donald Trump
Finance Minister Olaf Scholz: 'Germany Has a Special Responsibility'
Trapped in the Past: Increasing Headwinds for Angela Merkel
$ feedstail -1 -n5 -f '{noscript}' -u https://rss.nytimes.com/services/xml/rss/nyt/World.xml
Trump Sees End to North Korea Threat Despite Unclear Path Forward
Humanitarian Crisis Worsens in Yemen After Attack on Port
Who Is Behind Trump’s Links to Arab Princes? A Billionaire Friend
Trump-Kim Summit Creates New Anxieties for Asian Allies
New Delhi Dispatch: The Personal Wake-Up Call to Prayers, a Ramadan Tradition, Is Endangered
$ feedstail -1 -n5 -f '{noscript}' -u https://feeds.bbci.co.uk/news/world/rss.xml
North Korea sanctions remain until complete denuclearisation, says US
London Breed becomes San Francisco's first black female mayor
Chile police raid Catholic Church offices amid sex abuse scandal
Yemen war: Fighting rages over vital port of Hudaydah
Apple to close iPhone security loophole used by police
$ feedstail -1 -n5 -f '{noscript}' -u http://feeds.reuters.com/reuters/worldnews
https://www.qubes-os.org/news/2018/06/14/canary-16/
Dear Qubes Community,
We have published Qubes Canary #16. The text of this canary is
reproduced below. This canary and its accompanying signatures will
always be available in the Qubes Security Pack (qubes-secpack).
View Qubes Canary #16 in the qubes-secpack:
https://github.com/QubesOS/qubes-secpack/blob/master/canaries/canary-016-2018.txt
Learn about the qubes-secpack, including how to obtain, verify, and read
it:
https://www.qubes-os.org/security/pack/
View all past canaries:
https://www.qubes-os.org/security/canaries/
---===[ Qubes Canary #16 ]===---
Statements
-----------
The Qubes core developers who have digitally signed this file [1]
state the following:
1. The date of issue of this canary is June 14, 2018.
2. There have been 41 Qubes Security Bulletins published so far.
3. The Qubes Master Signing Key fingerprint is:
427F 11FD 0FAA 4B08 0123 F01C DDFA 1A3E 3687 9494
4. No warrants have ever been served to us with regard to the Qubes OS
Project (e.g. to hand out the private signing keys or to introduce
backdoors).
5. We plan to publish the next of these canary statements in the first
two weeks of October 2018. Special note should be taken if no new canary
is published by that time or if the list of statements changes without
plausible explanation.
Special announcements
----------------------
None.
Disclaimers and notes
----------------------
We would like to remind you that Qubes OS has been designed under the
assumption that all relevant infrastructure is permanently
compromised. This means that we assume NO trust in any of the servers
or services which host or provide any Qubes-related data, in
particular, software updates, source code repositories, and Qubes ISO
downloads.
This canary scheme is not infallible. Although signing the declaration
makes it very difficult for a third party to produce arbitrary
declarations, it does not prevent them from using force or other
means, like blackmail or compromising the signers' laptops, to coerce
us to produce false declarations.
The news feeds quoted below (Proof of freshness) serves to demonstrate
that this canary could not have been created prior to the date stated.
It shows that a series of canaries was not created in advance.
This declaration is merely a best effort and is provided without any
guarantee or warranty. It is not legally binding in any way to
anybody. None of the signers should be ever held legally responsible
for any of the statements made here.
Proof of freshness
-------------------
$ date -R -u
Thu, 14 Jun 2018 07:47:57 +0000
$ feedstail -1 -n5 -f '{noscript}' -u https://www.spiegel.de/international/index.rss
Rise of the Autocrats: Liberal Democracy Is Under Attack
Economic Trumpism: U.S. President Makes Life Tough for German Companies
The G-7 Fiasco: It's Time to Isolate Donald Trump
Finance Minister Olaf Scholz: 'Germany Has a Special Responsibility'
Trapped in the Past: Increasing Headwinds for Angela Merkel
$ feedstail -1 -n5 -f '{noscript}' -u https://rss.nytimes.com/services/xml/rss/nyt/World.xml
Trump Sees End to North Korea Threat Despite Unclear Path Forward
Humanitarian Crisis Worsens in Yemen After Attack on Port
Who Is Behind Trump’s Links to Arab Princes? A Billionaire Friend
Trump-Kim Summit Creates New Anxieties for Asian Allies
New Delhi Dispatch: The Personal Wake-Up Call to Prayers, a Ramadan Tradition, Is Endangered
$ feedstail -1 -n5 -f '{noscript}' -u https://feeds.bbci.co.uk/news/world/rss.xml
North Korea sanctions remain until complete denuclearisation, says US
London Breed becomes San Francisco's first black female mayor
Chile police raid Catholic Church offices amid sex abuse scandal
Yemen war: Fighting rages over vital port of Hudaydah
Apple to close iPhone security loophole used by police
$ feedstail -1 -n5 -f '{noscript}' -u http://feeds.reuters.com/reuters/worldnews
Pompeo says North Korea sanctions to remain until complete denuclearization
Saudi-led coalition keeps up Hodeidah assault before U.N. meeting
Italy still waiting for apology from France's Macron: deputy PM
In boost for Australian PM, right-wing party loses power to block his bills
'Where is Singapore?': Trump-Kim summit a PR coup for tiny city-state
$ curl -s 'https://blockchain.info/blocks/?format=json'
$ python3 -c 'import sys, json; print(json.load(sys.stdin)['\''blocks'\''][10]['\''hash'\''])'
000000000000000000212905769ee24bbb82122b44d6413974673a122a7cdaa8
Footnotes
----------
[1] This file should be signed in two ways: (1) via detached PGP
signatures by each of the signers, distributed together with this
canary in the qubes-secpack.git repo, and (2) via digital signatures
on the corresponding qubes-secpack.git repo tags. [2]
[2] Don't just trust the contents of this file blindly! Verify the
digital signatures!
Saudi-led coalition keeps up Hodeidah assault before U.N. meeting
Italy still waiting for apology from France's Macron: deputy PM
In boost for Australian PM, right-wing party loses power to block his bills
'Where is Singapore?': Trump-Kim summit a PR coup for tiny city-state
$ curl -s 'https://blockchain.info/blocks/?format=json'
$ python3 -c 'import sys, json; print(json.load(sys.stdin)['\''blocks'\''][10]['\''hash'\''])'
000000000000000000212905769ee24bbb82122b44d6413974673a122a7cdaa8
Footnotes
----------
[1] This file should be signed in two ways: (1) via detached PGP
signatures by each of the signers, distributed together with this
canary in the qubes-secpack.git repo, and (2) via digital signatures
on the corresponding qubes-secpack.git repo tags. [2]
[2] Don't just trust the contents of this file blindly! Verify the
digital signatures!
Marek Marczykowski-Górecki to speak at the Xen Developer and Design Summit 2018
https://www.qubes-os.org/news/2018/06/17/marek-marczykowski-gorecki-xen-summit-2018/
Marek Marczykowski-Górecki (https://www.qubes-os.org/team/#marek-marczykowski-g%C3%B3recki) will be speaking at this year’s Xen Developer and
Design Summit (https://www.lfasiallc.com/events/xensummit2018/). The summit will take place in Nanjing Jiangning, China from June
20–22, 2018. Marek will present on linux-based device model stubdomains in
Qubes OS. For more information about the summit, please see the announcement on
the Xen blog (https://blog.xenproject.org/2018/05/03/xen-project-announces-schedule-for-its-annual-developer-and-design-summi/).
https://www.qubes-os.org/news/2018/06/17/marek-marczykowski-gorecki-xen-summit-2018/
Marek Marczykowski-Górecki (https://www.qubes-os.org/team/#marek-marczykowski-g%C3%B3recki) will be speaking at this year’s Xen Developer and
Design Summit (https://www.lfasiallc.com/events/xensummit2018/). The summit will take place in Nanjing Jiangning, China from June
20–22, 2018. Marek will present on linux-based device model stubdomains in
Qubes OS. For more information about the summit, please see the announcement on
the Xen blog (https://blog.xenproject.org/2018/05/03/xen-project-announces-schedule-for-its-annual-developer-and-design-summi/).
Improving the Stealthiness of Virtual Machine Introspection on Xen
https://blog.xenproject.org/2018/06/21/improving-the-stealthiness-of-virtual-machine-introspection-on-xen/
This blog post comes from Stewart Sentanoe of the University of Passau. Stewart is an Assistant Professor of Security in Information Systems at the Faculty of Computer Science and Mathematics. He was recently a Google Summer of Code Intern working on the Honeynet Project. Project Introduction Virtual Machine Introspection Virtual Machine Introspection (VMI) is the process of examining and […]
https://blog.xenproject.org/2018/06/21/improving-the-stealthiness-of-virtual-machine-introspection-on-xen/
This blog post comes from Stewart Sentanoe of the University of Passau. Stewart is an Assistant Professor of Security in Information Systems at the Faculty of Computer Science and Mathematics. He was recently a Google Summer of Code Intern working on the Honeynet Project. Project Introduction Virtual Machine Introspection Virtual Machine Introspection (VMI) is the process of examining and […]
XSA-264, XSA-265, and XSA-266 do not affect the security of Qubes OS
https://www.qubes-os.org/news/2018/06/27/xsa-264-265-266-qubes-not-affected/
The Xen Project has published Xen Security Advisories 264, 265 and 266
(XSA-264, XSA-265, and XSA-266, respectively). 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/#264
https://www.qubes-os.org/security/xsa/#265
https://www.qubes-os.org/security/xsa/#266
https://www.qubes-os.org/news/2018/06/27/xsa-264-265-266-qubes-not-affected/
The Xen Project has published Xen Security Advisories 264, 265 and 266
(XSA-264, XSA-265, and XSA-266, respectively). 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/#264
https://www.qubes-os.org/security/xsa/#265
https://www.qubes-os.org/security/xsa/#266
Comment on Stealthy monitoring with Xen altp2m by Improving the Stealthiness of Virtual Machine Introspection on Xen | Xen Project Blog
https://blog.xenproject.org/2016/04/13/stealthy-monitoring-with-xen-altp2m/#comment-518
[…] There are two ways to set a breakpoint implemented by DRAKVUF using INT3 (0xCC opcode) and Xen altp2m. […]
https://blog.xenproject.org/2016/04/13/stealthy-monitoring-with-xen-altp2m/#comment-518
[…] There are two ways to set a breakpoint implemented by DRAKVUF using INT3 (0xCC opcode) and Xen altp2m. […]
Xen Project 4.7.6 is available!
https://blog.xenproject.org/2018/07/09/xen-project-4-7-6-is-available/
I am pleased to announce the release of the Xen 4.7.6. Xen Project maintenance releases are released in line with our Maintenance Release Policy. We recommend that all users of the 4.7 stable series update to the latest point release. The release is available from its git repositories xenbits.xen.org/gitweb/?p=xen.git;a=shortlog;h=refs/heads/stable-4.7 (tag RELEASE-4.7.6) or from the Xen […]
https://blog.xenproject.org/2018/07/09/xen-project-4-7-6-is-available/
I am pleased to announce the release of the Xen 4.7.6. Xen Project maintenance releases are released in line with our Maintenance Release Policy. We recommend that all users of the 4.7 stable series update to the latest point release. The release is available from its git repositories xenbits.xen.org/gitweb/?p=xen.git;a=shortlog;h=refs/heads/stable-4.7 (tag RELEASE-4.7.6) or from the Xen […]