Unikraft: Unleashing the Power of Unikernels
https://blog.xenproject.org/2017/12/05/unikraft-unleashing-the-power-of-unikernels/
This blog post was written by Dr. Felipe Huici, Chief Researcher, Systems and Machine Learning Group, at NEC Laboratories Europe The team at NEC Laboratories Europe spent quite a bit of time over the last few years developing unikernels – specialized virtual machine images targeting specific applications. This technology is fascinating to us because of […]
https://blog.xenproject.org/2017/12/05/unikraft-unleashing-the-power-of-unikernels/
This blog post was written by Dr. Felipe Huici, Chief Researcher, Systems and Machine Learning Group, at NEC Laboratories Europe The team at NEC Laboratories Europe spent quite a bit of time over the last few years developing unikernels – specialized virtual machine images targeting specific applications. This technology is fascinating to us because of […]
Xen Project Contributor Spotlight: Mike Latimer
https://blog.xenproject.org/2017/12/06/xen-project-contributor-spotlight-mike-latimer/
The Xen Project is comprised of a diverse set of member companies and contributors that are committed to the growth and success of the Xen Project Hypervisor. The Xen Project Hypervisor is a staple technology for server and cloud vendors, and is gaining traction in the embedded, security and automotive space. This blog series highlights […]
https://blog.xenproject.org/2017/12/06/xen-project-contributor-spotlight-mike-latimer/
The Xen Project is comprised of a diverse set of member companies and contributors that are committed to the growth and success of the Xen Project Hypervisor. The Xen Project Hypervisor is a staple technology for server and cloud vendors, and is gaining traction in the embedded, security and automotive space. This blog series highlights […]
Qubes Canary #14
https://www.qubes-os.org/news/2017/12/11/canary-14/
Dear Qubes community,
We have published Qubes Canary #14. 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 Canary #14 in the qubes-secpack:
https://github.com/QubesOS/qubes-secpack/blob/master/canaries/canary-014-2017.txt
Learn about the qubes-secpack, including how to obtain, verify, and read it:
https://www.qubes-os.org/security/pack/
View all past canaries:
https://www.qubes-os.org/security/canaries/
---===[ Qubes Canary #14 ]===---
Statements
-----------
The Qubes core developers who have digitally signed this file [1]
state the following:
1. The date of issue of this canary is December 10, 2017.
2. There have been 36 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 March 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
Sun, 10 Dec 2017 20:50:18 +0000
$ feedstail -1 -n5 -f '{noscript}' -u https://www.spiegel.de/international/index.rss
Trump's Jerusalem Folly: Time for Europe to Take the Lead on Peace
U.S. Economy: Trump Tax Plan Worries Europe
Alleged INF Treaty Violation: U.S. Demands NATO Action on Russian Missiles
Donald Trump and Jerusalem: 'I Don't See Potential Upsides'
Liberated Raqqa: The Stench of Death amid Hopes for Life
$ feedstail -1 -n5 -f '{noscript}' -u https://rss.nytimes.com/services/xml/rss/nyt/World.xml
For Older Venezuelans, Fleeing Crisis Means ‘Starting From Zero,’ Even at 90
Protests in Lebanon Near U.S. Embassy After Trump’s Jerusalem Decision
Jerusalem: It’s Tense, Crowded and Can Feel Like a Jail
The Interpreter: The Jerusalem Issue, Explained
Macron Steps Into Middle East Role as U.S. Retreats
$ feedstail -1 -n5 -f '{noscript}' -u https://feeds.bbci.co.uk/news/world/rss.xml
Netanyahu: Palestinians must face reality over Jerusalem
Nobel Peace Prize winner Ican warns nuclear war 'a tantrum away'
Actress Zaira Wasim: I was molested on flight
Star Wars: The Last Jedi - tributes to Carrie Fisher at LA premiere
North Korea: Urgent need to open channels, UN says after visit
$ feedstail -1 -n5 -f '{noscript}' -u http://feeds.reuters.com/reuters/worldnews
Palestinian stabs Israeli in Jerusalem; anti-Trump protest flares in Beirut
https://www.qubes-os.org/news/2017/12/11/canary-14/
Dear Qubes community,
We have published Qubes Canary #14. 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 Canary #14 in the qubes-secpack:
https://github.com/QubesOS/qubes-secpack/blob/master/canaries/canary-014-2017.txt
Learn about the qubes-secpack, including how to obtain, verify, and read it:
https://www.qubes-os.org/security/pack/
View all past canaries:
https://www.qubes-os.org/security/canaries/
---===[ Qubes Canary #14 ]===---
Statements
-----------
The Qubes core developers who have digitally signed this file [1]
state the following:
1. The date of issue of this canary is December 10, 2017.
2. There have been 36 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 March 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
Sun, 10 Dec 2017 20:50:18 +0000
$ feedstail -1 -n5 -f '{noscript}' -u https://www.spiegel.de/international/index.rss
Trump's Jerusalem Folly: Time for Europe to Take the Lead on Peace
U.S. Economy: Trump Tax Plan Worries Europe
Alleged INF Treaty Violation: U.S. Demands NATO Action on Russian Missiles
Donald Trump and Jerusalem: 'I Don't See Potential Upsides'
Liberated Raqqa: The Stench of Death amid Hopes for Life
$ feedstail -1 -n5 -f '{noscript}' -u https://rss.nytimes.com/services/xml/rss/nyt/World.xml
For Older Venezuelans, Fleeing Crisis Means ‘Starting From Zero,’ Even at 90
Protests in Lebanon Near U.S. Embassy After Trump’s Jerusalem Decision
Jerusalem: It’s Tense, Crowded and Can Feel Like a Jail
The Interpreter: The Jerusalem Issue, Explained
Macron Steps Into Middle East Role as U.S. Retreats
$ feedstail -1 -n5 -f '{noscript}' -u https://feeds.bbci.co.uk/news/world/rss.xml
Netanyahu: Palestinians must face reality over Jerusalem
Nobel Peace Prize winner Ican warns nuclear war 'a tantrum away'
Actress Zaira Wasim: I was molested on flight
Star Wars: The Last Jedi - tributes to Carrie Fisher at LA premiere
North Korea: Urgent need to open channels, UN says after visit
$ feedstail -1 -n5 -f '{noscript}' -u http://feeds.reuters.com/reuters/worldnews
Palestinian stabs Israeli in Jerusalem; anti-Trump protest flares in Beirut
Iraq holds victory parade after defeating Islamic State
With foes absent, Venezuela's socialists to gain from local vote
UK's Johnson meets Iran president as he lobbies for jailed aid worker
Honduras tribunal says partial vote recount shows same result
$ curl -s 'https://blockchain.info/blocks/?format=json'
$ python3 -c 'import sys, json; print(json.load(sys.stdin)['\''blocks'\''][10]['\''hash'\''])'
0000000000000000005f669c5a625a7fbebec488d864723433d9e5c50b1cb01b
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!
With foes absent, Venezuela's socialists to gain from local vote
UK's Johnson meets Iran president as he lobbies for jailed aid worker
Honduras tribunal says partial vote recount shows same result
$ curl -s 'https://blockchain.info/blocks/?format=json'
$ python3 -c 'import sys, json; print(json.load(sys.stdin)['\''blocks'\''][10]['\''hash'\''])'
0000000000000000005f669c5a625a7fbebec488d864723433d9e5c50b1cb01b
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!
Xen Project Contributor Spotlight: Irby Thompson
https://blog.xenproject.org/2017/12/12/xen-project-contributor-spotlight-irby-thompson/
The Xen Project is comprised of a diverse set of member companies and contributors that are committed to the growth and success of the Xen Project Hypervisor. The Xen Project Hypervisor is a staple technology for server and cloud vendors, and is gaining traction in the embedded, security and automotive space. This blog series highlights […]
https://blog.xenproject.org/2017/12/12/xen-project-contributor-spotlight-irby-thompson/
The Xen Project is comprised of a diverse set of member companies and contributors that are committed to the growth and success of the Xen Project Hypervisor. The Xen Project Hypervisor is a staple technology for server and cloud vendors, and is gaining traction in the embedded, security and automotive space. This blog series highlights […]
XSA-248 through XSA-251 do not affect the security of Qubes OS
https://www.qubes-os.org/news/2017/12/12/xsa-245-251-qubes-not-affected/
The Xen Project has published Xen Security Advisories 248 through 251 (XSA-248 through XSA-251).
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/#248
https://www.qubes-os.org/security/xsa/#249
https://www.qubes-os.org/security/xsa/#250
https://www.qubes-os.org/security/xsa/#251
https://www.qubes-os.org/news/2017/12/12/xsa-245-251-qubes-not-affected/
The Xen Project has published Xen Security Advisories 248 through 251 (XSA-248 through XSA-251).
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/#248
https://www.qubes-os.org/security/xsa/#249
https://www.qubes-os.org/security/xsa/#250
https://www.qubes-os.org/security/xsa/#251
What’s New in the Xen Project Hypervisor 4.10
https://blog.xenproject.org/2017/12/14/whats-new-in-the-xen-project-hypervisor-4-10/
I am pleased to announce the release of the Xen Project Hypervisor 4.10. As always, we focused on improving code quality, security hardening as well as enabling new features. The Xen Project Hypervisor 4.10 continues to take a security-first approach with improved architecture and more centralized documentation. The release is equipped with the latest hardware […]
https://blog.xenproject.org/2017/12/14/whats-new-in-the-xen-project-hypervisor-4-10/
I am pleased to announce the release of the Xen Project Hypervisor 4.10. As always, we focused on improving code quality, security hardening as well as enabling new features. The Xen Project Hypervisor 4.10 continues to take a security-first approach with improved architecture and more centralized documentation. The release is equipped with the latest hardware […]
Xen Project Member Spotlight: Bitdefender
https://blog.xenproject.org/2017/12/18/xen-project-member-spotlight-bitdefender/
The Xen Project is comprised of a diverse set of member companies and contributors that are committed to the growth and success of the Xen Project Hypervisor. The Xen Project Hypervisor is a staple technology for server and cloud vendors, and is gaining traction in the embedded, security and automotive space. This blog series highlights […]
https://blog.xenproject.org/2017/12/18/xen-project-member-spotlight-bitdefender/
The Xen Project is comprised of a diverse set of member companies and contributors that are committed to the growth and success of the Xen Project Hypervisor. The Xen Project Hypervisor is a staple technology for server and cloud vendors, and is gaining traction in the embedded, security and automotive space. This blog series highlights […]
Comment on Unikraft: Unleashing the Power of Unikernels by Unikraft: Unleashing the Power of Unikernels – Nerd Junkie
https://blog.xenproject.org/2017/12/05/unikraft-unleashing-the-power-of-unikernels/#comment-421
[…] This article originally appeared at Xen Project. […]
https://blog.xenproject.org/2017/12/05/unikraft-unleashing-the-power-of-unikernels/#comment-421
[…] This article originally appeared at Xen Project. […]
Comment on Unikraft: Unleashing the Power of Unikernels by Проект Xen представил Unikraft для выполнения приложений поверх гипервизора
https://blog.xenproject.org/2017/12/05/unikraft-unleashing-the-power-of-unikernels/#comment-423
[…] гипервизора Xen анонсировали проект Unikraft, в рамках которого развивается […]
https://blog.xenproject.org/2017/12/05/unikraft-unleashing-the-power-of-unikernels/#comment-423
[…] гипервизора Xen анонсировали проект Unikraft, в рамках которого развивается […]
Announcing the Windows PV HID Drivers
https://blog.xenproject.org/2017/12/20/announcing-the-windows-pv-hid-drivers/
Some recent patches to the QEMU source fix a long standing problem where the PV vkbd backend was unable to function correctly without the PV fb backend, which effectively made it pointless to implement PV HID (i.e. keyboard and mouse) frontends for HVM guests. Now that the problem has been fixed, I’m happy to announce […]
https://blog.xenproject.org/2017/12/20/announcing-the-windows-pv-hid-drivers/
Some recent patches to the QEMU source fix a long standing problem where the PV vkbd backend was unable to function correctly without the PV fb backend, which effectively made it pointless to implement PV HID (i.e. keyboard and mouse) frontends for HVM guests. Now that the problem has been fixed, I’m happy to announce […]
Comment on What’s New in the Xen Project Hypervisor 4.10 by fbifido
https://blog.xenproject.org/2017/12/12/whats-new-in-the-xen-project-hypervisor-4-10/#comment-436
When are we going to get native hyper-converge like pernixdata-fvp?
https://blog.xenproject.org/2017/12/12/whats-new-in-the-xen-project-hypervisor-4-10/#comment-436
When are we going to get native hyper-converge like pernixdata-fvp?
Comment on What’s New in the Xen Project Hypervisor 4.10 by Xen Hypervisor 4.10 Focuses on Security and Better ARM Support
https://blog.xenproject.org/2017/12/12/whats-new-in-the-xen-project-hypervisor-4-10/#comment-438
[…] Xen Project released version 4.10 of their hypervisor with an improved architecture for x86, support for ARM processor hardware […]
https://blog.xenproject.org/2017/12/12/whats-new-in-the-xen-project-hypervisor-4-10/#comment-438
[…] Xen Project released version 4.10 of their hypervisor with an improved architecture for x86, support for ARM processor hardware […]
Announcement regarding XSA-254 (Meltdown and Spectre attacks)
https://www.qubes-os.org/news/2018/01/04/xsa-254-meltdown-spectre/
The Qubes Security Team is currently investigating the extent to which
XSA-254 (https://xenbits.xen.org/xsa/advisory-254.html) (and the Meltdown (https://meltdownattack.com/) and Spectre (https://spectreattack.com/) attacks more generally)
affect the security of Qubes OS. The practical impact of these attacks
on Qubes is currently unclear. While the Qubes Security Team is a
member of the Xen predisclosure list (https://www.xenproject.org/security-policy.html), XSA-254 (https://xenbits.xen.org/xsa/advisory-254.html) was disclosed on an
accelerated timetable ahead of schedule, so our team has not yet had a
chance to analyze these attacks, nor has the Xen Project released any
patches associated with XSA-254 (https://xenbits.xen.org/xsa/advisory-254.html). We are continuing to monitor the
situation closely. Once the Security Team makes a determination about
the impact on Qubes, we will make another announcement, update the
XSA Tracker (https://www.qubes-os.org/security/xsa/), and, if appropriate, issue a Qubes Security Bulletin (https://www.qubes-os.org/security/bulletins/)
with information about patching.
https://www.qubes-os.org/news/2018/01/04/xsa-254-meltdown-spectre/
The Qubes Security Team is currently investigating the extent to which
XSA-254 (https://xenbits.xen.org/xsa/advisory-254.html) (and the Meltdown (https://meltdownattack.com/) and Spectre (https://spectreattack.com/) attacks more generally)
affect the security of Qubes OS. The practical impact of these attacks
on Qubes is currently unclear. While the Qubes Security Team is a
member of the Xen predisclosure list (https://www.xenproject.org/security-policy.html), XSA-254 (https://xenbits.xen.org/xsa/advisory-254.html) was disclosed on an
accelerated timetable ahead of schedule, so our team has not yet had a
chance to analyze these attacks, nor has the Xen Project released any
patches associated with XSA-254 (https://xenbits.xen.org/xsa/advisory-254.html). We are continuing to monitor the
situation closely. Once the Security Team makes a determination about
the impact on Qubes, we will make another announcement, update the
XSA Tracker (https://www.qubes-os.org/security/xsa/), and, if appropriate, issue a Qubes Security Bulletin (https://www.qubes-os.org/security/bulletins/)
with information about patching.
Xen Project Spectre/Meltdown FAQ
https://blog.xenproject.org/2018/01/04/xen-project-spectremeltdown-faq/
Google’s Project Zero announced several information leak vulnerabilities affecting all modern superscalar processors. Details can be found on their blog, and in the Xen Project Advisory 254. To help our users understand the impact and our next steps forward, we put together the following FAQ. Note that we will update the FAQ as new information […]
https://blog.xenproject.org/2018/01/04/xen-project-spectremeltdown-faq/
Google’s Project Zero announced several information leak vulnerabilities affecting all modern superscalar processors. Details can be found on their blog, and in the Xen Project Advisory 254. To help our users understand the impact and our next steps forward, we put together the following FAQ. Note that we will update the FAQ as new information […]
Fedora 26 TemplateVM Upgrade
https://www.qubes-os.org/news/2018/01/06/fedora-26-upgrade/
Fedora 25 reached EOL (end-of-life (https://fedoraproject.org/wiki/Fedora_Release_Life_Cycle#Maintenance_Schedule)) on 2017-12-12. We sincerely
apologize for our failure to provide timely notice of this event. It
is strongly recommend that all Qubes users upgrade their Fedora 25
TemplateVMs and StandaloneVMs to Fedora 26 immediately. We provide
step-by-step upgrade instructions (https://www.qubes-os.org/doc/template/fedora/upgrade-25-to-26/) for upgrading your existing
TemplateVMs and StandaloneVMs in-place on both Qubes 3.2 and Qubes
4.0. 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 26 TemplateVM packages through the
official Qubes repositories, which you can get with the following
commands (in dom0).
Standard Fedora 26 TemplateVM:
$ sudo qubes-dom0-update qubes-template-fedora-26
Minimal (https://www.qubes-os.org/doc/templates/fedora-minimal/) Fedora 26 TemplateVM:
$ sudo qubes-dom0-update qubes-template-fedora-26-minimal
After upgrading to a Fedora 26 TemplateVM, 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 (https://www.qubes-os.org/doc/template/fedora/upgrade-25-to-26/)
for your specific version.
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/01/06/fedora-26-upgrade/
Fedora 25 reached EOL (end-of-life (https://fedoraproject.org/wiki/Fedora_Release_Life_Cycle#Maintenance_Schedule)) on 2017-12-12. We sincerely
apologize for our failure to provide timely notice of this event. It
is strongly recommend that all Qubes users upgrade their Fedora 25
TemplateVMs and StandaloneVMs to Fedora 26 immediately. We provide
step-by-step upgrade instructions (https://www.qubes-os.org/doc/template/fedora/upgrade-25-to-26/) for upgrading your existing
TemplateVMs and StandaloneVMs in-place on both Qubes 3.2 and Qubes
4.0. 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 26 TemplateVM packages through the
official Qubes repositories, which you can get with the following
commands (in dom0).
Standard Fedora 26 TemplateVM:
$ sudo qubes-dom0-update qubes-template-fedora-26
Minimal (https://www.qubes-os.org/doc/templates/fedora-minimal/) Fedora 26 TemplateVM:
$ sudo qubes-dom0-update qubes-template-fedora-26-minimal
After upgrading to a Fedora 26 TemplateVM, 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 (https://www.qubes-os.org/doc/template/fedora/upgrade-25-to-26/)
for your specific version.
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.
Comment on Xen Project Spectre/Meltdown FAQ by Meltdown und Spectre - Updates bringen Performance Probleme - JACOB Blog
https://blog.xenproject.org/2018/01/04/xen-project-spectremeltdown-faq/#comment-447
[…] Security Advisory (XSA-254) / FAQ […]
https://blog.xenproject.org/2018/01/04/xen-project-spectremeltdown-faq/#comment-447
[…] Security Advisory (XSA-254) / FAQ […]
QSB #37: Information leaks due to processor speculative execution bugs (XSA-254, Meltdown & Spectre)
https://www.qubes-os.org/news/2018/01/11/qsb-37/
Dear Qubes Community,
We have just published Qubes Security Bulletin (QSB) #37:
Information leaks due to processor speculative execution bugs.
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 #37 in the qubes-secpack:
https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-037-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-254 in the XSA Tracker:
https://www.qubes-os.org/security/xsa/#254
---===[ Qubes Security Bulletin #37 ]===---
January 11, 2018
Information leaks due to processor speculative execution bugs
Summary
========
On the night of January 3, two independent groups of researchers
announced the results of their months-long work into abusing modern
processors' so-called speculative mode to leak secrets from the system's
privileged memory [1][2][3][4]. As a response, the Xen Security Team
published Xen Security Advisory 254 [5]. The Xen Security Team did _not_
previously share information about these problems via their (non-public)
security pre-disclosure list, of which the Qubes Security Team is a
member.
In the limited time we've had to analyze the issue, we've come to the
following conclusions about the practical impact on Qubes OS users and
possible remedies. We'll also share a plan to address the issues in a
more systematic way in the coming weeks.
Practical impact and limiting factors for Qubes users
======================================================
## Fully virtualized VMs offer significant protection against Meltdown
Meltdown, the most reliable attack of the three discussed, cannot be
exploited _from_ a fully-virtualized (i.e. HVM or PVH) VM. It does not
matter whether the _target_ VM (i.e. the one from which the attacker
wants to steal secrets) is fully-virtualized. In Qubes 3.x, all VMs are
para-virtualized (PV) by default, though users can choose to create
fully-virtualized VMs. PV VMs do not protect against the Meltdown
attack. In Qubes 4.0, almost all VMs are fully-virtualized by default
and thus offer protection. However, the fully-virtualized VMs in Qubes
3.2 and in release candidates 1-3 of Qubes 4.0 still rely on PV-based
"stub domains", making it possible for an attacker who can chain another
exploit for qemu to attempt the Meltdown attack.
## Virtualization makes at least one variant of Spectre seem difficult
Of the two Spectre variants, it _seems_ that at least one of them might
be significantly harder to exploit under Xen than under monolithic
systems because there are significantly fewer options for the attacker
to interact with the hypervisor.
## All attacks are read-only
It's important to stress that these attacks allow only _reading_ memory,
not modifying it. This means that an attacker cannot use Spectre or
Meltdown to plant any backdoors or otherwise compromise the system in
any persistent way. Thanks to the Qubes OS template mechanism, which is
used by default for all user and system qubes (AppVMs and ServiceVMs),
simply restarting a VM should bring it back to a good known state for
most attacks, wiping out the potential attacking code in the
TemplateBasedVM (unless an attacker found a way to put triggers within
the user's home directory; please see [8] for more discussion).
## Only running VMs are vulnerable
Since Qubes OS is a memory-hungry system, it seems that an attacker
would only be able to steal secrets from VMs running concurrently with
the attacking VM. This is because any pages from shutdown VMs will
typically very quickly get allocated to other, running VMs and get wiped
https://www.qubes-os.org/news/2018/01/11/qsb-37/
Dear Qubes Community,
We have just published Qubes Security Bulletin (QSB) #37:
Information leaks due to processor speculative execution bugs.
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 #37 in the qubes-secpack:
https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-037-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-254 in the XSA Tracker:
https://www.qubes-os.org/security/xsa/#254
---===[ Qubes Security Bulletin #37 ]===---
January 11, 2018
Information leaks due to processor speculative execution bugs
Summary
========
On the night of January 3, two independent groups of researchers
announced the results of their months-long work into abusing modern
processors' so-called speculative mode to leak secrets from the system's
privileged memory [1][2][3][4]. As a response, the Xen Security Team
published Xen Security Advisory 254 [5]. The Xen Security Team did _not_
previously share information about these problems via their (non-public)
security pre-disclosure list, of which the Qubes Security Team is a
member.
In the limited time we've had to analyze the issue, we've come to the
following conclusions about the practical impact on Qubes OS users and
possible remedies. We'll also share a plan to address the issues in a
more systematic way in the coming weeks.
Practical impact and limiting factors for Qubes users
======================================================
## Fully virtualized VMs offer significant protection against Meltdown
Meltdown, the most reliable attack of the three discussed, cannot be
exploited _from_ a fully-virtualized (i.e. HVM or PVH) VM. It does not
matter whether the _target_ VM (i.e. the one from which the attacker
wants to steal secrets) is fully-virtualized. In Qubes 3.x, all VMs are
para-virtualized (PV) by default, though users can choose to create
fully-virtualized VMs. PV VMs do not protect against the Meltdown
attack. In Qubes 4.0, almost all VMs are fully-virtualized by default
and thus offer protection. However, the fully-virtualized VMs in Qubes
3.2 and in release candidates 1-3 of Qubes 4.0 still rely on PV-based
"stub domains", making it possible for an attacker who can chain another
exploit for qemu to attempt the Meltdown attack.
## Virtualization makes at least one variant of Spectre seem difficult
Of the two Spectre variants, it _seems_ that at least one of them might
be significantly harder to exploit under Xen than under monolithic
systems because there are significantly fewer options for the attacker
to interact with the hypervisor.
## All attacks are read-only
It's important to stress that these attacks allow only _reading_ memory,
not modifying it. This means that an attacker cannot use Spectre or
Meltdown to plant any backdoors or otherwise compromise the system in
any persistent way. Thanks to the Qubes OS template mechanism, which is
used by default for all user and system qubes (AppVMs and ServiceVMs),
simply restarting a VM should bring it back to a good known state for
most attacks, wiping out the potential attacking code in the
TemplateBasedVM (unless an attacker found a way to put triggers within
the user's home directory; please see [8] for more discussion).
## Only running VMs are vulnerable
Since Qubes OS is a memory-hungry system, it seems that an attacker
would only be able to steal secrets from VMs running concurrently with
the attacking VM. This is because any pages from shutdown VMs will
typically very quickly get allocated to other, running VMs and get wiped