QSB-086: Speculative security issues on AMD CPUs (XSA-422)
https://www.qubes-os.org/news/2022/11/08/qsb-086/
We have just published Qubes Security Bulletin (QSB) 086: Speculative security issues on AMD CPUs (XSA-422) (https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-086-2022.txt). 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) (https://www.qubes-os.org/security/pack/). More information about QSBs, including a complete historical list, is available here (https://www.qubes-os.org/security/qsb/).
---===[ Qubes Security Bulletin 086 ]===---
2022-11-08
Speculative security issues on AMD CPUs (XSA-422)
User action required
---------------------
Users must install the following specific packages in order to address
the issues discussed in this bulletin:
For Qubes 4.1, in dom0:
- Xen packages, version 4.14.5-13
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. [1] Once available, the packages are to be installed
via the Qubes Update tool or its command-line equivalents. [2]
Dom0 must be restarted afterward in order for the updates to take
effect.
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.
Summary
--------
On 2022-11-08, the Xen Project published XSA-422, "x86: Multiple
speculative security issues" [3]:
| Researchers have discovered that on some AMD CPUs, the
| implementation of IBPB (Indirect Branch Prediction Barrier) does not
| behave according to the specification.
|
| Specifically, IBPB fails to properly flush the RAS (Return Address
| Stack, also RSB - Return Stack Buffer - in Intel terminology; one of
| the hardware prediction structures), allowing attacker controlled
| values to survive across a deliberate attempt to purge said values.
|
| AMD have allocated CVE-2022-23824.
XSA-422 also describes a second AMD vulnerability. However, since it
is believed not to affect Xen, and therefore not to affect Qubes OS,
it is omitted here.
Impact
-------
On Qubes OS installations with affected CPUs, a VM running in PV mode
may be capable of inferring the memory contents of other running VMs,
including dom0. In the default Qubes OS configuration, only the
stubdomains for HVMs are in a position to exploit this vulnerability
in order to attack other VMs. (Dom0 also runs in PV mode, but it is
fully trusted.)
Only certain AMD CPUs are affected. Please see AMD-SB-1040 [4] for the
official list of affected models.
(Note: XSA-422 states that Xen versions prior to 4.16 are not affected
by this vulnerability. While Qubes OS uses a Xen version prior to
4.16, we have backported a Xen performance optimization [5] that
assumes that IBPB works as previously specified. Therefore, the
version of Xen used in Qubes is affected by this vulnerability even
though its version numbers is lower than 4.16.)
Credits
--------
See the original Xen Security Advisory.
References
-----------
[1] https://www.qubes-os.org/doc/testing/
[2] https://www.qubes-os.org/doc/how-to-update/
[3] https://xenbits.xen.org/xsa/advisory-422.html
[4] https://www.amd.com/en/corporate/product-security/bulletin/amd-sb-1040
[5] https://github.com/QubesOS/qubes-vmm-xen/blob/v4.14.5-12/patch-0001-x86-spec-ctrl-Skip-RSB-overwriting-when-safe-to-do-s.patch
--
The Qubes Security Team
https://www.qubes-os.org/security/
https://www.qubes-os.org/news/2022/11/08/qsb-086/
We have just published Qubes Security Bulletin (QSB) 086: Speculative security issues on AMD CPUs (XSA-422) (https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-086-2022.txt). 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) (https://www.qubes-os.org/security/pack/). More information about QSBs, including a complete historical list, is available here (https://www.qubes-os.org/security/qsb/).
---===[ Qubes Security Bulletin 086 ]===---
2022-11-08
Speculative security issues on AMD CPUs (XSA-422)
User action required
---------------------
Users must install the following specific packages in order to address
the issues discussed in this bulletin:
For Qubes 4.1, in dom0:
- Xen packages, version 4.14.5-13
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. [1] Once available, the packages are to be installed
via the Qubes Update tool or its command-line equivalents. [2]
Dom0 must be restarted afterward in order for the updates to take
effect.
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.
Summary
--------
On 2022-11-08, the Xen Project published XSA-422, "x86: Multiple
speculative security issues" [3]:
| Researchers have discovered that on some AMD CPUs, the
| implementation of IBPB (Indirect Branch Prediction Barrier) does not
| behave according to the specification.
|
| Specifically, IBPB fails to properly flush the RAS (Return Address
| Stack, also RSB - Return Stack Buffer - in Intel terminology; one of
| the hardware prediction structures), allowing attacker controlled
| values to survive across a deliberate attempt to purge said values.
|
| AMD have allocated CVE-2022-23824.
XSA-422 also describes a second AMD vulnerability. However, since it
is believed not to affect Xen, and therefore not to affect Qubes OS,
it is omitted here.
Impact
-------
On Qubes OS installations with affected CPUs, a VM running in PV mode
may be capable of inferring the memory contents of other running VMs,
including dom0. In the default Qubes OS configuration, only the
stubdomains for HVMs are in a position to exploit this vulnerability
in order to attack other VMs. (Dom0 also runs in PV mode, but it is
fully trusted.)
Only certain AMD CPUs are affected. Please see AMD-SB-1040 [4] for the
official list of affected models.
(Note: XSA-422 states that Xen versions prior to 4.16 are not affected
by this vulnerability. While Qubes OS uses a Xen version prior to
4.16, we have backported a Xen performance optimization [5] that
assumes that IBPB works as previously specified. Therefore, the
version of Xen used in Qubes is affected by this vulnerability even
though its version numbers is lower than 4.16.)
Credits
--------
See the original Xen Security Advisory.
References
-----------
[1] https://www.qubes-os.org/doc/testing/
[2] https://www.qubes-os.org/doc/how-to-update/
[3] https://xenbits.xen.org/xsa/advisory-422.html
[4] https://www.amd.com/en/corporate/product-security/bulletin/amd-sb-1040
[5] https://github.com/QubesOS/qubes-vmm-xen/blob/v4.14.5-12/patch-0001-x86-spec-ctrl-Skip-RSB-overwriting-when-safe-to-do-s.patch
--
The Qubes Security Team
https://www.qubes-os.org/security/
QSB-087: Qrexec: Injection of unsanitized data into log output
https://www.qubes-os.org/news/2022/11/23/qsb-087/
We have just published Qubes Security Bulletin (QSB) 087: Qrexec: Injection of unsanitized data into log output (https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-087-2022.txt). 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) (https://www.qubes-os.org/security/pack/). More information about QSBs, including a complete historical list, is available here (https://www.qubes-os.org/security/qsb/).
---===[ Qubes Security Bulletin 087 ]===---
2022-11-23
Qrexec: Injection of unsanitized data into log output
User action required
---------------------
Users must install the following specific packages in order to address
the issues discussed in this bulletin:
For Qubes 4.1, in templates, standalones and dom0:
- qrexec packages version 4.1.19
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. [1] Once available, the packages are to be installed
via the Qubes Update tool or its command-line equivalents. [2]
Summary
--------
Due to a bug in qrexec [3], a malicious qube that is allowed to call a
qrexec service inside of another qube can inject unsanitized data into
the log output of a process that handles incoming qrexec calls in the
receiving qube. This log output may end up in
`/var/log/qubes/qrexec.*.log`, `~/.xsession-errors`, or systemd's
journal.
Impact
-------
An attacker could use this vulnerability in order to inject malicious
data, such as terminal control codes, into log output in the hope that
this data will be processed in a unsafe way, for example, by writing it
directly to a potentially-vulnerable terminal emulator.
In the default Qubes OS configuration, for example, there are qrexec
services like `qubes.WindowIconUpdater` that any qube can call in dom0.
An attacker who gains control of an untrusted qube could inject data
containing malicious terminal control sequences into
`/var/log/qubes/qrexec.*.log` in dom0. If the user views that log in a
terminal emulator in a way that doesn't filter terminal escape codes (by
simply using `cat` on the file, for example), the malicious data might
then exploit a hypothetical bug in the terminal emulator.
Note that this attack scenario, as described, has several layered
requirements:
1. The user must voluntarily open a log file containing malicious data
(or otherwise take action that causes the log file data to be
parsed).
2. There must exist an independent vulnerability in the user's terminal
emulator or in whichever program parses the log. (In other words, the
attacker must chain independent vulnerabilities together.)
3. If using a terminal emulator, a command-line tool that does not
filter control codes must be used. (`journalctl` prevents the display
of unsafe sequences by default, but many other tools do not.)
To be clear, the scenario in which the attacker uses the
`qubes.WindowIconUpdater` service in order to exploit a hypothetical bug
in a terminal emulator is just one conceivable scenario for how an
attacker might exploit the vulnerability described in this bulletin. It
is not the only way in which this vulnerability could be exploited, and
the requirements listed for this scenario may not necessarily apply to
other scenarios featuring different types of attacks (for example, using
other qrexec services and exploiting other software that handles log
output). Rather, this example is merely intended as an aid for
understanding the nature of the vulnerability.
Discussion
-----------
Qubes OS features a framework known as "qrexec," which allows different
qubes to communicate with each other in a controlled manner. [3][4]
https://www.qubes-os.org/news/2022/11/23/qsb-087/
We have just published Qubes Security Bulletin (QSB) 087: Qrexec: Injection of unsanitized data into log output (https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-087-2022.txt). 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) (https://www.qubes-os.org/security/pack/). More information about QSBs, including a complete historical list, is available here (https://www.qubes-os.org/security/qsb/).
---===[ Qubes Security Bulletin 087 ]===---
2022-11-23
Qrexec: Injection of unsanitized data into log output
User action required
---------------------
Users must install the following specific packages in order to address
the issues discussed in this bulletin:
For Qubes 4.1, in templates, standalones and dom0:
- qrexec packages version 4.1.19
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. [1] Once available, the packages are to be installed
via the Qubes Update tool or its command-line equivalents. [2]
Summary
--------
Due to a bug in qrexec [3], a malicious qube that is allowed to call a
qrexec service inside of another qube can inject unsanitized data into
the log output of a process that handles incoming qrexec calls in the
receiving qube. This log output may end up in
`/var/log/qubes/qrexec.*.log`, `~/.xsession-errors`, or systemd's
journal.
Impact
-------
An attacker could use this vulnerability in order to inject malicious
data, such as terminal control codes, into log output in the hope that
this data will be processed in a unsafe way, for example, by writing it
directly to a potentially-vulnerable terminal emulator.
In the default Qubes OS configuration, for example, there are qrexec
services like `qubes.WindowIconUpdater` that any qube can call in dom0.
An attacker who gains control of an untrusted qube could inject data
containing malicious terminal control sequences into
`/var/log/qubes/qrexec.*.log` in dom0. If the user views that log in a
terminal emulator in a way that doesn't filter terminal escape codes (by
simply using `cat` on the file, for example), the malicious data might
then exploit a hypothetical bug in the terminal emulator.
Note that this attack scenario, as described, has several layered
requirements:
1. The user must voluntarily open a log file containing malicious data
(or otherwise take action that causes the log file data to be
parsed).
2. There must exist an independent vulnerability in the user's terminal
emulator or in whichever program parses the log. (In other words, the
attacker must chain independent vulnerabilities together.)
3. If using a terminal emulator, a command-line tool that does not
filter control codes must be used. (`journalctl` prevents the display
of unsafe sequences by default, but many other tools do not.)
To be clear, the scenario in which the attacker uses the
`qubes.WindowIconUpdater` service in order to exploit a hypothetical bug
in a terminal emulator is just one conceivable scenario for how an
attacker might exploit the vulnerability described in this bulletin. It
is not the only way in which this vulnerability could be exploited, and
the requirements listed for this scenario may not necessarily apply to
other scenarios featuring different types of attacks (for example, using
other qrexec services and exploiting other software that handles log
output). Rather, this example is merely intended as an aid for
understanding the nature of the vulnerability.
Discussion
-----------
Qubes OS features a framework known as "qrexec," which allows different
qubes to communicate with each other in a controlled manner. [3][4]
👍3
These interactions are restricted by the system's RPC policies. [5] In
particular, qrexec can be used to allow less trusted qubes to
communicate with more trusted qubes, including dom0.
Normally, the calling side can send data to the remote services'
standard input and receive its standard output, standard error, and exit
code data. Since it handles untrusted data flows, qrexec is designed
under the assumption that an adversary will use it in order to launch an
attack against one qube from another qube. Therefore, qrexec treats
incoming data as untrusted and carefully sanitizes it. For example, when
qrexec output is connected to a terminal, `qrexec-client` and
`qrexec-client-vm` remove terminal control sequences.
However, due to a mistake in qrexec message type handling, the calling
side can send data marked as "standard error" (`MSG_DATA_STDERR`), and
the remote side will print it to the standard error of the process
handling incoming qrexec connections. This data flow was not expected.
Such messages should be rejected, as they are expected only in the other
direction. Consequently, this data is not appropriately sanitized, and
potentially-malicious data may end up in log output.
Credits
--------
This issue was discovered by Demi Marie Obenour.
References
-----------
[1] https://www.qubes-os.org/doc/testing/
[2] https://www.qubes-os.org/doc/how-to-update/
[3] https://www.qubes-os.org/doc/qrexec/
[4] https://www.qubes-os.org/doc/qrexec-internals/
[5] https://www.qubes-os.org/doc/rpc-policy/
--
The Qubes Security Team
https://www.qubes-os.org/security/
particular, qrexec can be used to allow less trusted qubes to
communicate with more trusted qubes, including dom0.
Normally, the calling side can send data to the remote services'
standard input and receive its standard output, standard error, and exit
code data. Since it handles untrusted data flows, qrexec is designed
under the assumption that an adversary will use it in order to launch an
attack against one qube from another qube. Therefore, qrexec treats
incoming data as untrusted and carefully sanitizes it. For example, when
qrexec output is connected to a terminal, `qrexec-client` and
`qrexec-client-vm` remove terminal control sequences.
However, due to a mistake in qrexec message type handling, the calling
side can send data marked as "standard error" (`MSG_DATA_STDERR`), and
the remote side will print it to the standard error of the process
handling incoming qrexec connections. This data flow was not expected.
Such messages should be rejected, as they are expected only in the other
direction. Consequently, this data is not appropriately sanitized, and
potentially-malicious data may end up in log output.
Credits
--------
This issue was discovered by Demi Marie Obenour.
References
-----------
[1] https://www.qubes-os.org/doc/testing/
[2] https://www.qubes-os.org/doc/how-to-update/
[3] https://www.qubes-os.org/doc/qrexec/
[4] https://www.qubes-os.org/doc/qrexec-internals/
[5] https://www.qubes-os.org/doc/rpc-policy/
--
The Qubes Security Team
https://www.qubes-os.org/security/
👍5
Qubes Canary 033
https://www.qubes-os.org/news/2022/12/04/canary-033/
We have published Qubes Canary 033. 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 033 in the qubes-secpack:
https://github.com/QubesOS/qubes-secpack/blob/master/canaries/canary-033-2022.txt
Learn how to obtain and authenticate the qubes-secpack and all the
signatures it contains:
https://www.qubes-os.org/security/pack/
View all past canaries:
https://www.qubes-os.org/security/canary/
---===[ Qubes Canary 033 ]===---
Statements
-----------
The Qubes security team members who have digitally signed this file [1]
state the following:
1. The date of issue of this canary is December 04, 2022.
2. There have been 87 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
fourteen days of March 2023. 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 proof of freshness provided below 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
-------------------
Sun, 04 Dec 2022 03:11:56 +0000
Source: DER SPIEGEL - International (https://www.spiegel.de/international/index.rss)
Friends or Frenemies?: Significant Trans-Atlantic Divides Emerge in Global Chip War
The Russian Mobilization: One Soldier's Effort to Avoid the War
Tragedy in Mariupol: The Boy Who Lost His Family But Not His Hope
A Year with Angela Merkel: "You're Done with Power Politics"
Fears of Chinese Aggression Grow in Taiwan: "Where Are We Supposed to Go?"
Source: NYT > World News (https://rss.nytimes.com/services/xml/rss/nyt/World.xml)
He Returned a Dazed Soldier to the Russians. Ukraine Calls It Treason.
Landslide Tragedy Turns Italy’s Focus to Illegal Construction
Why Is Rahul Gandhi Walking 2,000 Miles Across India?
How China’s Police Used Phones and Faces to Track Protesters
Ukraine Calls for Evacuations From a Russian-Controlled Area
Source: BBC News - World (https://feeds.bbci.co.uk/news/world/rss.xml)
Cyril Ramaphosa: South Africa leader won't resign, says spokesman
Ukraine war: Zelensky calls West's Russian oil cap 'weak'
Ukraine war: New images show Russian army base built in occupied Mariupol
Elnaz Rekabi: Family home of Iranian climber demolished
Columbia peace talks with leftist ELN rebels make progress
Source: Blockchain.info
00000000000000000000955f2976b1fbff0d0c47c262ea3ae6410e43f8218fb7
Footnotes
----------
https://www.qubes-os.org/news/2022/12/04/canary-033/
We have published Qubes Canary 033. 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 033 in the qubes-secpack:
https://github.com/QubesOS/qubes-secpack/blob/master/canaries/canary-033-2022.txt
Learn how to obtain and authenticate the qubes-secpack and all the
signatures it contains:
https://www.qubes-os.org/security/pack/
View all past canaries:
https://www.qubes-os.org/security/canary/
---===[ Qubes Canary 033 ]===---
Statements
-----------
The Qubes security team members who have digitally signed this file [1]
state the following:
1. The date of issue of this canary is December 04, 2022.
2. There have been 87 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
fourteen days of March 2023. 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 proof of freshness provided below 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
-------------------
Sun, 04 Dec 2022 03:11:56 +0000
Source: DER SPIEGEL - International (https://www.spiegel.de/international/index.rss)
Friends or Frenemies?: Significant Trans-Atlantic Divides Emerge in Global Chip War
The Russian Mobilization: One Soldier's Effort to Avoid the War
Tragedy in Mariupol: The Boy Who Lost His Family But Not His Hope
A Year with Angela Merkel: "You're Done with Power Politics"
Fears of Chinese Aggression Grow in Taiwan: "Where Are We Supposed to Go?"
Source: NYT > World News (https://rss.nytimes.com/services/xml/rss/nyt/World.xml)
He Returned a Dazed Soldier to the Russians. Ukraine Calls It Treason.
Landslide Tragedy Turns Italy’s Focus to Illegal Construction
Why Is Rahul Gandhi Walking 2,000 Miles Across India?
How China’s Police Used Phones and Faces to Track Protesters
Ukraine Calls for Evacuations From a Russian-Controlled Area
Source: BBC News - World (https://feeds.bbci.co.uk/news/world/rss.xml)
Cyril Ramaphosa: South Africa leader won't resign, says spokesman
Ukraine war: Zelensky calls West's Russian oil cap 'weak'
Ukraine war: New images show Russian army base built in occupied Mariupol
Elnaz Rekabi: Family home of Iranian climber demolished
Columbia peace talks with leftist ELN rebels make progress
Source: Blockchain.info
00000000000000000000955f2976b1fbff0d0c47c262ea3ae6410e43f8218fb7
Footnotes
----------
👍1
[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! Instructions for doing so are documented here:
https://www.qubes-os.org/security/pack/
--
The Qubes Security Team
https://www.qubes-os.org/security/
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! Instructions for doing so are documented here:
https://www.qubes-os.org/security/pack/
--
The Qubes Security Team
https://www.qubes-os.org/security/
👍1
XSAs released on 2022-12-06
https://www.qubes-os.org/news/2022/12/06/xsas-released-on-2022-12-06/
The Xen Project (https://xenproject.org/) has released one or more Xen security advisories (XSAs) (https://xenbits.xen.org/xsa/).
The security of Qubes OS is not affected.
Therefore, no user action is required.
XSAs that DO affect the security of Qubes OS
The following XSAs do affect the security of Qubes OS:
(none)
XSAs that DO NOT affect the security of Qubes OS
The following XSAs do not affect the security of Qubes OS, and no user action is necessary:
XSA-423 (denial-of-service only)
XSA-424 (denial-of-service only)
About this announcement
Qubes OS uses the Xen hypervisor (https://wiki.xenproject.org/wiki/Xen_Project_Software_Overview) as part of its architecture (https://www.qubes-os.org/doc/architecture/). When the Xen Project (https://xenproject.org/) publicly discloses a vulnerability in the Xen hypervisor, they issue a notice called a Xen security advisory (XSA) (https://xenproject.org/developers/security-policy/). Vulnerabilities in the Xen hypervisor sometimes have security implications for Qubes OS. When they do, we issue a notice called a Qubes security bulletin (QSB) (https://www.qubes-os.org/security/qsb/). (QSBs are also issued for non-Xen vulnerabilities.) However, QSBs can provide only positive confirmation that certain XSAs do affect the security of Qubes OS. QSBs cannot provide negative confirmation that other XSAs do not affect the security of Qubes OS. Therefore, we also maintain an XSA tracker (https://www.qubes-os.org/security/xsa/), which is a comprehensive list of all XSAs publicly disclosed to date, including whether each one affects the security of Qubes OS. When new XSAs are published, we add them to the XSA tracker and publish a notice like this one in order to inform Qubes users that a new batch of XSAs has been released and whether each one affects the security of Qubes OS.
https://www.qubes-os.org/news/2022/12/06/xsas-released-on-2022-12-06/
The Xen Project (https://xenproject.org/) has released one or more Xen security advisories (XSAs) (https://xenbits.xen.org/xsa/).
The security of Qubes OS is not affected.
Therefore, no user action is required.
XSAs that DO affect the security of Qubes OS
The following XSAs do affect the security of Qubes OS:
(none)
XSAs that DO NOT affect the security of Qubes OS
The following XSAs do not affect the security of Qubes OS, and no user action is necessary:
XSA-423 (denial-of-service only)
XSA-424 (denial-of-service only)
About this announcement
Qubes OS uses the Xen hypervisor (https://wiki.xenproject.org/wiki/Xen_Project_Software_Overview) as part of its architecture (https://www.qubes-os.org/doc/architecture/). When the Xen Project (https://xenproject.org/) publicly discloses a vulnerability in the Xen hypervisor, they issue a notice called a Xen security advisory (XSA) (https://xenproject.org/developers/security-policy/). Vulnerabilities in the Xen hypervisor sometimes have security implications for Qubes OS. When they do, we issue a notice called a Qubes security bulletin (QSB) (https://www.qubes-os.org/security/qsb/). (QSBs are also issued for non-Xen vulnerabilities.) However, QSBs can provide only positive confirmation that certain XSAs do affect the security of Qubes OS. QSBs cannot provide negative confirmation that other XSAs do not affect the security of Qubes OS. Therefore, we also maintain an XSA tracker (https://www.qubes-os.org/security/xsa/), which is a comprehensive list of all XSAs publicly disclosed to date, including whether each one affects the security of Qubes OS. When new XSAs are published, we add them to the XSA tracker and publish a notice like this one in order to inform Qubes users that a new batch of XSAs has been released and whether each one affects the security of Qubes OS.
Fedora 35 reaches EOL on 2022-12-13
https://www.qubes-os.org/news/2022/12/08/fedora-35-reaches-eol-on-2022-12-13/
The Fedora Project has announced (https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org/thread/OGTVKLX7OXBYCEUQ66UY4YK3T6QHAYW5/) that Fedora 35 will reach EOL (end-of-life (https://fedoraproject.org/wiki/End_of_life)) on 2022-12-13. We strongly recommend that all users upgrade (https://www.qubes-os.org/doc/templates/fedora/#upgrading) their Fedora templates and standalones to Fedora 36 no later than 2022-12-13.
We provide fresh Fedora 36 template packages 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). Alternatively, we also provide step-by-step instructions for performing an in-place upgrade (https://www.qubes-os.org/doc/templates/fedora/in-place-upgrade/) of an existing Fedora template. After upgrading your templates, 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).
For a complete list of template releases that are supported for your specific Qubes release, see our supported template releases (https://www.qubes-os.org/doc/supported-releases/#templates).
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-releases/#note-on-dom0-and-eol).
https://www.qubes-os.org/news/2022/12/08/fedora-35-reaches-eol-on-2022-12-13/
The Fedora Project has announced (https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org/thread/OGTVKLX7OXBYCEUQ66UY4YK3T6QHAYW5/) that Fedora 35 will reach EOL (end-of-life (https://fedoraproject.org/wiki/End_of_life)) on 2022-12-13. We strongly recommend that all users upgrade (https://www.qubes-os.org/doc/templates/fedora/#upgrading) their Fedora templates and standalones to Fedora 36 no later than 2022-12-13.
We provide fresh Fedora 36 template packages 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). Alternatively, we also provide step-by-step instructions for performing an in-place upgrade (https://www.qubes-os.org/doc/templates/fedora/in-place-upgrade/) of an existing Fedora template. After upgrading your templates, 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).
For a complete list of template releases that are supported for your specific Qubes release, see our supported template releases (https://www.qubes-os.org/doc/supported-releases/#templates).
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-releases/#note-on-dom0-and-eol).
🤮3🐳1
Support the Qubes OS Project via Proton's charity fundraiser!
https://www.qubes-os.org/news/2022/12/16/proton-charity-fundraiser/
The Qubes OS Project is grateful to have been selected as one of the beneficiaries of this year’s Proton (https://proton.me/) charity fundraiser alongside so many other wonderful organizations. The continued support of the privacy community means the world to us! For details about the fundraiser and how you can participate, please see the official Proton blog post: The 2022 Lifetime Account Charity Fundraiser has started! (https://proton.me/blog/2022-lifetime-account-charity-fundraiser)
https://www.qubes-os.org/news/2022/12/16/proton-charity-fundraiser/
The Qubes OS Project is grateful to have been selected as one of the beneficiaries of this year’s Proton (https://proton.me/) charity fundraiser alongside so many other wonderful organizations. The continued support of the privacy community means the world to us! For details about the fundraiser and how you can participate, please see the official Proton blog post: The 2022 Lifetime Account Charity Fundraiser has started! (https://proton.me/blog/2022-lifetime-account-charity-fundraiser)
❤11
⚠️ This channel is updated ASAP after devs make an announcement to the project.
Do you need Help? Do you want to participate in community conversations?
Join the group!
https://news.1rj.ru/str/+QROgxw4yJttXvDNF
Do you need Help? Do you want to participate in community conversations?
Join the group!
https://news.1rj.ru/str/+QROgxw4yJttXvDNF
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.
❤2🥰2😍1
XSAs released on 2023-01-25
https://www.qubes-os.org/news/2023/01/27/xsas-released-on-2023-01-25/
The Xen Project (https://xenproject.org/) has released one or more Xen security advisories (XSAs) (https://xenbits.xen.org/xsa/).
The security of Qubes OS is not affected.
Therefore, no user action is required.
XSAs that DO affect the security of Qubes OS
The following XSAs do affect the security of Qubes OS:
(none)
XSAs that DO NOT affect the security of Qubes OS
The following XSAs do not affect the security of Qubes OS, and no user action is necessary:
XSA-425 (Qubes 4.1 does not use the affected Xen version; denial-of-service only)
About this announcement
Qubes OS uses the Xen hypervisor (https://wiki.xenproject.org/wiki/Xen_Project_Software_Overview) as part of its architecture (https://www.qubes-os.org/doc/architecture/). When the Xen Project (https://xenproject.org/) publicly discloses a vulnerability in the Xen hypervisor, they issue a notice called a Xen security advisory (XSA) (https://xenproject.org/developers/security-policy/). Vulnerabilities in the Xen hypervisor sometimes have security implications for Qubes OS. When they do, we issue a notice called a Qubes security bulletin (QSB) (https://www.qubes-os.org/security/qsb/). (QSBs are also issued for non-Xen vulnerabilities.) However, QSBs can provide only positive confirmation that certain XSAs do affect the security of Qubes OS. QSBs cannot provide negative confirmation that other XSAs do not affect the security of Qubes OS. Therefore, we also maintain an XSA tracker (https://www.qubes-os.org/security/xsa/), which is a comprehensive list of all XSAs publicly disclosed to date, including whether each one affects the security of Qubes OS. When new XSAs are published, we add them to the XSA tracker and publish a notice like this one in order to inform Qubes users that a new batch of XSAs has been released and whether each one affects the security of Qubes OS.
https://www.qubes-os.org/news/2023/01/27/xsas-released-on-2023-01-25/
The Xen Project (https://xenproject.org/) has released one or more Xen security advisories (XSAs) (https://xenbits.xen.org/xsa/).
The security of Qubes OS is not affected.
Therefore, no user action is required.
XSAs that DO affect the security of Qubes OS
The following XSAs do affect the security of Qubes OS:
(none)
XSAs that DO NOT affect the security of Qubes OS
The following XSAs do not affect the security of Qubes OS, and no user action is necessary:
XSA-425 (Qubes 4.1 does not use the affected Xen version; denial-of-service only)
About this announcement
Qubes OS uses the Xen hypervisor (https://wiki.xenproject.org/wiki/Xen_Project_Software_Overview) as part of its architecture (https://www.qubes-os.org/doc/architecture/). When the Xen Project (https://xenproject.org/) publicly discloses a vulnerability in the Xen hypervisor, they issue a notice called a Xen security advisory (XSA) (https://xenproject.org/developers/security-policy/). Vulnerabilities in the Xen hypervisor sometimes have security implications for Qubes OS. When they do, we issue a notice called a Qubes security bulletin (QSB) (https://www.qubes-os.org/security/qsb/). (QSBs are also issued for non-Xen vulnerabilities.) However, QSBs can provide only positive confirmation that certain XSAs do affect the security of Qubes OS. QSBs cannot provide negative confirmation that other XSAs do not affect the security of Qubes OS. Therefore, we also maintain an XSA tracker (https://www.qubes-os.org/security/xsa/), which is a comprehensive list of all XSAs publicly disclosed to date, including whether each one affects the security of Qubes OS. When new XSAs are published, we add them to the XSA tracker and publish a notice like this one in order to inform Qubes users that a new batch of XSAs has been released and whether each one affects the security of Qubes OS.
👍4
TrenchBoot Anti Evil Maid for Qubes OS
https://www.qubes-os.org/news/2023/01/31/trenchboot-aem-for-qubes-os/
Editor’s note: The following is a guest post by Michal Zygowski from 3mdeb (https://3mdeb.com/) on the work they’ve been doing to upgrade Anti Evil Maid (AEM) (https://www.qubes-os.org/doc/anti-evil-maid/). The original post can be found on the 3mdeb blog (https://blog.3mdeb.com/2023/2023-01-31-trenchboot-aem-for-qubesos/). This work was made possible through generous donations (https://www.qubes-os.org/donate/) from the Qubes community via OpenCollective (https://opencollective.com/qubes-os). We are immensely grateful to the Qubes community for your continued support and to 3mdeb for contributing this valuable work.
Abstract
Qubes OS Anti Evil Maid (AEM) software heavily depends on the
availability of the DRTM technologies to prevent the Evil Maid
attacks. However, the project has not evolved much since the
beginning of 2018 and froze on the support of TPM 1.2 with Intel TXT
in legacy boot mode (BIOS). In the post we show how existing
solution can be replaced with TrenchBoot and how one can install it
on the Qubes OS. Also the post will also briefly explain how
TrenchBoot opens the door for future TPM 2.0 and UEFI support for
AEM.
Introduction
As Qubes OS users, promoters, and developers, we understand how essential it is
to be aware of the latest developments in maintaining the security of your
favorite operating system. We’re excited to share our plans to integrate the
TrenchBoot Project into Qubes OS’s new Anti-Evil Maid (AEM) implementation. As
you may know, traditional firmware security measures like UEFI Secure Boot and
measured boot, even with a Static Root of Trust (SRT), may only sometimes be
enough to ensure a completely secure environment for your operating system.
Compromised firmware may allow for the injection of malicious software into
your system, making it difficult to detect. To overcome these limitations, many
silicon vendors have started implementing Dynamic Root of Trust (DRT)
technologies to establish a secure environment for operating system launch and
integrity measurements. We’re excited to take advantage of these advancements
through integration with the TrenchBoot Project (https://trenchboot.org/).
The usage of DRT technologies like Intel Trusted Execution Technology (TXT) or
AMD Secure Startup is becoming more and more significant; for example, Dynamic
Root of Trust for Measurement (DRTM) requirements of Microsoft Secured Core PCs (https://docs.microsoft.com/en-us/windows-hardware/design/device-experiences/oem-highly-secure#what-makes-a-secured-core-pc).
DRTM has yet to find its place in open-source projects, but that gradually
changes. The demand for having firmware-independent Roots of Trust is
increasing, and projects that satisfy this demand are growing TrenchBoot is a
framework that allows individuals and projects to build security engines to
perform launch integrity actions for their systems. The framework builds upon
Boot Integrity Technologies (BITs) that establish one or more Roots of Trust
(RoT) from which a degree of confidence that integrity actions were not
subverted.
Qubes OS Anti Evil Maid (AEM) (https://blog.invisiblethings.org/2011/09/07/anti-evil-maid.html)
software heavily depends on the availability of DRTM technologies to prevent
Evil Maid attacks. However, the project hasn’t evolved much since the beginning
of 2018 and froze on the support of TPM 1.2 with Intel TXT in legacy boot mode
(BIOS). Because of that, the usage of this security software is effectively
limited to older Intel machines only. TPM 1.2 implemented SHA1 hashing
algorithm, which is nowadays considered weak in the era of forever-increasing
computer performance and quantum computing. The solution to this problem comes
with a newer TPM 2.0 with more agile cryptographic algorithms and SHA256
implementation by default.
The post will present the TrenchBoot solution for Qubes OS AEM replacing the
https://www.qubes-os.org/news/2023/01/31/trenchboot-aem-for-qubes-os/
Editor’s note: The following is a guest post by Michal Zygowski from 3mdeb (https://3mdeb.com/) on the work they’ve been doing to upgrade Anti Evil Maid (AEM) (https://www.qubes-os.org/doc/anti-evil-maid/). The original post can be found on the 3mdeb blog (https://blog.3mdeb.com/2023/2023-01-31-trenchboot-aem-for-qubesos/). This work was made possible through generous donations (https://www.qubes-os.org/donate/) from the Qubes community via OpenCollective (https://opencollective.com/qubes-os). We are immensely grateful to the Qubes community for your continued support and to 3mdeb for contributing this valuable work.
Abstract
Qubes OS Anti Evil Maid (AEM) software heavily depends on the
availability of the DRTM technologies to prevent the Evil Maid
attacks. However, the project has not evolved much since the
beginning of 2018 and froze on the support of TPM 1.2 with Intel TXT
in legacy boot mode (BIOS). In the post we show how existing
solution can be replaced with TrenchBoot and how one can install it
on the Qubes OS. Also the post will also briefly explain how
TrenchBoot opens the door for future TPM 2.0 and UEFI support for
AEM.
Introduction
As Qubes OS users, promoters, and developers, we understand how essential it is
to be aware of the latest developments in maintaining the security of your
favorite operating system. We’re excited to share our plans to integrate the
TrenchBoot Project into Qubes OS’s new Anti-Evil Maid (AEM) implementation. As
you may know, traditional firmware security measures like UEFI Secure Boot and
measured boot, even with a Static Root of Trust (SRT), may only sometimes be
enough to ensure a completely secure environment for your operating system.
Compromised firmware may allow for the injection of malicious software into
your system, making it difficult to detect. To overcome these limitations, many
silicon vendors have started implementing Dynamic Root of Trust (DRT)
technologies to establish a secure environment for operating system launch and
integrity measurements. We’re excited to take advantage of these advancements
through integration with the TrenchBoot Project (https://trenchboot.org/).
The usage of DRT technologies like Intel Trusted Execution Technology (TXT) or
AMD Secure Startup is becoming more and more significant; for example, Dynamic
Root of Trust for Measurement (DRTM) requirements of Microsoft Secured Core PCs (https://docs.microsoft.com/en-us/windows-hardware/design/device-experiences/oem-highly-secure#what-makes-a-secured-core-pc).
DRTM has yet to find its place in open-source projects, but that gradually
changes. The demand for having firmware-independent Roots of Trust is
increasing, and projects that satisfy this demand are growing TrenchBoot is a
framework that allows individuals and projects to build security engines to
perform launch integrity actions for their systems. The framework builds upon
Boot Integrity Technologies (BITs) that establish one or more Roots of Trust
(RoT) from which a degree of confidence that integrity actions were not
subverted.
Qubes OS Anti Evil Maid (AEM) (https://blog.invisiblethings.org/2011/09/07/anti-evil-maid.html)
software heavily depends on the availability of DRTM technologies to prevent
Evil Maid attacks. However, the project hasn’t evolved much since the beginning
of 2018 and froze on the support of TPM 1.2 with Intel TXT in legacy boot mode
(BIOS). Because of that, the usage of this security software is effectively
limited to older Intel machines only. TPM 1.2 implemented SHA1 hashing
algorithm, which is nowadays considered weak in the era of forever-increasing
computer performance and quantum computing. The solution to this problem comes
with a newer TPM 2.0 with more agile cryptographic algorithms and SHA256
implementation by default.
The post will present the TrenchBoot solution for Qubes OS AEM replacing the
👍1
current TPM 1.2 and Intel TXT-only implementation. The advantage of TrenchBoot
solution over existing Trusted Boot (https://sourceforge.net/p/tboot/wiki/Home/)
is the easier future integration of AMD platform support, as well as TPM 2.0
and UEFI mode support.
Before we dive into the technical details, it is important to highlight that
this achievement was made possible through the generous contributions of Qubes
OS community via OpenCollective. We would like to express our gratitude and
extend a special thank you to all who have supported our favourite operating
system. To continue supporting Qubes OS, please consider donating through
OpenCollective page (https://opencollective.com/qubes-os). Thank you for your
continued support!
Modificationts to original Qubes OS AEM
To replace the original implementation of Qubes OS AE
there weren’t any AEM noscripts modifications necessary. What actually had to
change is GRUB and Xen Hypervisor (and Trusted Boot - to be removed). Why? one
may ask… First of all, one must understand the role of a Trusted Boot
(TBOOT).
Trusted Boot DRTM flow
solution over existing Trusted Boot (https://sourceforge.net/p/tboot/wiki/Home/)
is the easier future integration of AMD platform support, as well as TPM 2.0
and UEFI mode support.
Before we dive into the technical details, it is important to highlight that
this achievement was made possible through the generous contributions of Qubes
OS community via OpenCollective. We would like to express our gratitude and
extend a special thank you to all who have supported our favourite operating
system. To continue supporting Qubes OS, please consider donating through
OpenCollective page (https://opencollective.com/qubes-os). Thank you for your
continued support!
Modificationts to original Qubes OS AEM
To replace the original implementation of Qubes OS AE
there weren’t any AEM noscripts modifications necessary. What actually had to
change is GRUB and Xen Hypervisor (and Trusted Boot - to be removed). Why? one
may ask… First of all, one must understand the role of a Trusted Boot
(TBOOT).
Trusted Boot DRTM flow
(Source: A Practical Guide to TPM 2.0 (https://link.springer.com/book/10.1007/978-1-4302-6584-9))
The main role of Trusted Boot was to prepare a platform to be launched with
Intel TXT (Intel’s DRTM technology) in an operating system agnostic way. It has
been achieved by loading a tboot kernel with Multiboot protocol and the other
system components as the modules. That way, TBOOT is the main kernel that
starts first and prepares the platform for TXT launch. When the platform is
ready, then tboot performs the TXT launch. The control is passed to SINIT
Authenticated Code Module (ACM), a binary signed and provided by Intel designed
for DRTM technology. SINIT ACM uses TXT to measure the operating system
components in a secure manner. Then the control is handed back to the tboot
kernel, which checks if the operation was successful and boots the target
operating system.
Although the tboot tried to be as OS agnostic as possible, some tboot presence
awareness from the operating system is needed because the application processor
cores (all cores except the main one) are left in a special state after TXT
launch and cannot be woken up like in traditional boot process. To solve this
problem, tboot installs a special processor wakeup procedure in the memory,
which OS must call into to start the processor cores. Only then OS may
initialize the processor per its own requirements.
As one can see, the process is complex in the case of Intel TXT. Migration of
all tboot responsibilities was not trivial and has been divided into the work
on both GRUB and Xen Hypervisor side of Qubes OS.
GRUB modifications
The main role of Trusted Boot was to prepare a platform to be launched with
Intel TXT (Intel’s DRTM technology) in an operating system agnostic way. It has
been achieved by loading a tboot kernel with Multiboot protocol and the other
system components as the modules. That way, TBOOT is the main kernel that
starts first and prepares the platform for TXT launch. When the platform is
ready, then tboot performs the TXT launch. The control is passed to SINIT
Authenticated Code Module (ACM), a binary signed and provided by Intel designed
for DRTM technology. SINIT ACM uses TXT to measure the operating system
components in a secure manner. Then the control is handed back to the tboot
kernel, which checks if the operation was successful and boots the target
operating system.
Although the tboot tried to be as OS agnostic as possible, some tboot presence
awareness from the operating system is needed because the application processor
cores (all cores except the main one) are left in a special state after TXT
launch and cannot be woken up like in traditional boot process. To solve this
problem, tboot installs a special processor wakeup procedure in the memory,
which OS must call into to start the processor cores. Only then OS may
initialize the processor per its own requirements.
As one can see, the process is complex in the case of Intel TXT. Migration of
all tboot responsibilities was not trivial and has been divided into the work
on both GRUB and Xen Hypervisor side of Qubes OS.
GRUB modifications
👍2
In order to fulfill the same role as tboot, GRUB had to learn how to prepare
the platform and perform the TXT launch. Most of the work for that particular
part has been done by Oracle Team working on TrenchBoot for GRUB (https://www.mail-archive.com/grub-devel@gnu.org/msg30167.html).
That work, however, covered the Linux kernel TXT launch only. What still had to
be done was the Multiboot2 protocol support in GRUB to be able to TXT launch a
Xen Hypervisor. The patches have been prepared for the respective Qubes GRUB
package (https://github.com/3mdeb/qubes-grub2/pull/2).
Xen modifications
the platform and perform the TXT launch. Most of the work for that particular
part has been done by Oracle Team working on TrenchBoot for GRUB (https://www.mail-archive.com/grub-devel@gnu.org/msg30167.html).
That work, however, covered the Linux kernel TXT launch only. What still had to
be done was the Multiboot2 protocol support in GRUB to be able to TXT launch a
Xen Hypervisor. The patches have been prepared for the respective Qubes GRUB
package (https://github.com/3mdeb/qubes-grub2/pull/2).
Xen modifications
Analogically to GRUB, Xen had to take over some responsibilities from tboot.
Due to the Intel TXT requirements for the boot process, a new entry point had
to be developed to which SINIT ACM will return control. The new entry point was
responsible for saving information that a TXT launch happened and cleaning up
the processor state so that the booting of the Xen kernel could continue with
the standard Multiboot2 path. Among others, if Xen detected TXT launch, it had
to perform the special processor cores wakeup process (which has been rewritten
from TrenchBoot Linux patches to Xen native code) and measure external
components before using them (that is the Xen parameters, Dom0 Linux kernel,
initrd and Dom0 parameters). Xen also had to reserve the memory regions used by
Intel TXT, as when tboot was used. The relevant source code for the respective
Qubes Xen package is available here (https://github.com/3mdeb/qubes-vmm-xen/pull/1).
Installation and verification of TrenchBoot AEM on Qubes OS
For a seamless deployment and installation of TrenchBoot AEM, the modifications
Qubes OS components compilation. Those patches have been presented earlier with
have been converted to patches which are applied to projects’ sources during
links to Pull Requests. It allows building ready-to-use RPM packages that can
be installed directly on an installed Qubes OS system. The pre-built packages
can be downloaded from here (https://3mdeb.com/open-source-firmware/QubesOS/trenchboot_aem_poc/).
The packages have been covered with SHA512 sums signed with 3mdeb’s
Qubes OS TrenchBoot AEM open-source software release 0.x signing key
available on 3mdeb-secpack repository (https://github.com/3mdeb/3mdeb-secpack/blob/master/open-source-software/qubes-os-trenchboot-aem-open-source-software-release-0.x-signing-key.asc).
To verify the RPM packages, fetch the key with the following command:
gpg --fetch https://raw.githubusercontent.com/3mdeb/3mdeb-secpack/master/open-source-software/qubes-os-trenchboot-aem-open-source-software-release-0.x-signing-key.asc
and then to verify the packages, please run:
$ gpg --verify sha512sums.sig sha512sums
gpg: Signature made wto, 31 sty 2023, 11:06:06 CET
gpg: using RSA key 3405D1E4509CD18A3EA762245D289020C07114F3
gpg: Good signature from "Qubes OS TrenchBoot AEM open-source software release 0.x signing key" [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the owner.
Primary key fingerprint: 3405 D1E4 509C D18A 3EA7 6224 5D28 9020 C071 14F3
$ sha512sum -c sha512sums
grub2-common-2.06-1.fc32.noarch.rpm: OK
grub2-tools-extra-2.06-1.fc32.x86_64.rpm: OK
xen-licenses-4.17.0-3.fc32.x86_64.rpm: OK
grub2-pc-2.06-1.fc32.x86_64.rpm: OK
xen-libs-4.17.0-3.fc32.x86_64.rpm: OK
grub2-tools-2.06-1.fc32.x86_64.rpm: OK
xen-hypervisor-4.17.0-3.fc32.x86_64.rpm: OK
grub2-pc-modules-2.06-1.fc32.noarch.rpm: OK
xen-runtime-4.17.0-3.fc32.x86_64.rpm: OK
grub2-tools-minimal-2.06-1.fc32.x86_64.rpm: OK
python3-xen-4.17.0-3.fc32.x86_64.rpm: OK
xen-4.17.0-3.fc32.x86_64.rpm: OK
Check if GPG returns a good signature and if yes, check if the RPM checksum
matches. All files must be in the same directory for the procedure to work.
Note, in order to use the TrenchBoot AEM for Qubes OS, you have to own a
TXT-capable platform with TXT-enabled firmware offering legacy boot. Such
platform can be Dell OptiPlex 7010. You can visit
Dasharo with Intel TXT support blog post (https://blog.3mdeb.com/2022/2022-03-17-optiplex-txt/)
to learn more about such hardware and firmware. If you want to get OptiPlex
with Dasharo pre-installed, you can get one from
3mdeb shop (https://3mdeb.com/shop/open-source-hardware/dasharo-dell-optiplex-7010-sff-i3-i7-8gb-32gb-ram-copy/).
Building Xen and GRUB packages
If you are not interested in compilation, skip to the next section (https://www.qubes-os.org/#installing-xen-and-grub-packages).
Due to the Intel TXT requirements for the boot process, a new entry point had
to be developed to which SINIT ACM will return control. The new entry point was
responsible for saving information that a TXT launch happened and cleaning up
the processor state so that the booting of the Xen kernel could continue with
the standard Multiboot2 path. Among others, if Xen detected TXT launch, it had
to perform the special processor cores wakeup process (which has been rewritten
from TrenchBoot Linux patches to Xen native code) and measure external
components before using them (that is the Xen parameters, Dom0 Linux kernel,
initrd and Dom0 parameters). Xen also had to reserve the memory regions used by
Intel TXT, as when tboot was used. The relevant source code for the respective
Qubes Xen package is available here (https://github.com/3mdeb/qubes-vmm-xen/pull/1).
Installation and verification of TrenchBoot AEM on Qubes OS
For a seamless deployment and installation of TrenchBoot AEM, the modifications
Qubes OS components compilation. Those patches have been presented earlier with
have been converted to patches which are applied to projects’ sources during
links to Pull Requests. It allows building ready-to-use RPM packages that can
be installed directly on an installed Qubes OS system. The pre-built packages
can be downloaded from here (https://3mdeb.com/open-source-firmware/QubesOS/trenchboot_aem_poc/).
The packages have been covered with SHA512 sums signed with 3mdeb’s
Qubes OS TrenchBoot AEM open-source software release 0.x signing key
available on 3mdeb-secpack repository (https://github.com/3mdeb/3mdeb-secpack/blob/master/open-source-software/qubes-os-trenchboot-aem-open-source-software-release-0.x-signing-key.asc).
To verify the RPM packages, fetch the key with the following command:
gpg --fetch https://raw.githubusercontent.com/3mdeb/3mdeb-secpack/master/open-source-software/qubes-os-trenchboot-aem-open-source-software-release-0.x-signing-key.asc
and then to verify the packages, please run:
$ gpg --verify sha512sums.sig sha512sums
gpg: Signature made wto, 31 sty 2023, 11:06:06 CET
gpg: using RSA key 3405D1E4509CD18A3EA762245D289020C07114F3
gpg: Good signature from "Qubes OS TrenchBoot AEM open-source software release 0.x signing key" [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the owner.
Primary key fingerprint: 3405 D1E4 509C D18A 3EA7 6224 5D28 9020 C071 14F3
$ sha512sum -c sha512sums
grub2-common-2.06-1.fc32.noarch.rpm: OK
grub2-tools-extra-2.06-1.fc32.x86_64.rpm: OK
xen-licenses-4.17.0-3.fc32.x86_64.rpm: OK
grub2-pc-2.06-1.fc32.x86_64.rpm: OK
xen-libs-4.17.0-3.fc32.x86_64.rpm: OK
grub2-tools-2.06-1.fc32.x86_64.rpm: OK
xen-hypervisor-4.17.0-3.fc32.x86_64.rpm: OK
grub2-pc-modules-2.06-1.fc32.noarch.rpm: OK
xen-runtime-4.17.0-3.fc32.x86_64.rpm: OK
grub2-tools-minimal-2.06-1.fc32.x86_64.rpm: OK
python3-xen-4.17.0-3.fc32.x86_64.rpm: OK
xen-4.17.0-3.fc32.x86_64.rpm: OK
Check if GPG returns a good signature and if yes, check if the RPM checksum
matches. All files must be in the same directory for the procedure to work.
Note, in order to use the TrenchBoot AEM for Qubes OS, you have to own a
TXT-capable platform with TXT-enabled firmware offering legacy boot. Such
platform can be Dell OptiPlex 7010. You can visit
Dasharo with Intel TXT support blog post (https://blog.3mdeb.com/2022/2022-03-17-optiplex-txt/)
to learn more about such hardware and firmware. If you want to get OptiPlex
with Dasharo pre-installed, you can get one from
3mdeb shop (https://3mdeb.com/shop/open-source-hardware/dasharo-dell-optiplex-7010-sff-i3-i7-8gb-32gb-ram-copy/).
Building Xen and GRUB packages
If you are not interested in compilation, skip to the next section (https://www.qubes-os.org/#installing-xen-and-grub-packages).
To not make the post excessively long, the procedure for building packages
has been put into TrenchBoot SDK documentation (https://github.com/TrenchBoot/trenchboot-sdk/blob/3d56ca7b27bb038629fd838819a1050006725a1e/Documentation/build_qubes_packages.md).
Follow the instructions in the file to build the TrenchBoot AEM packages.
Installing Xen and GRUB packages
The following process was carried out and tested on
Qubes OS 4.2 (https://openqa.qubes-os.org/tests/55506#downloads).
In order to install the packages one has to send the Xen and GRUB RPMs to the
Dom0. Please note that moving any external files or data to Dom0 is potentially
dangerous. Ensure that your environment is safe and the RPMs have the right
checksums after copying them to Dom0. If you don’t know how to copy files to
Dom0, refer to the Qubes OS documentation (https://www.qubes-os.org/doc/how-to-copy-from-dom0/#copying-to-dom0).
Even before installing packages, it is required to enable the
current-testing repository to avoid the need to install additional
dependencies:
sudo qubes-dom0-update --enablerepo=qubes-dom0-current-testing
If the RPMs are inside Dom0, install them with the following command
(assuming you downloaded all of them to one directory):
sudo dnf update \
python3-xen-4.17.0-3.fc32.x86_64.rpm \
xen-4.17.0-3.fc32.x86_64.rpm \
xen-hypervisor-4.17.0-3.fc32.x86_64.rpm \
xen-libs-4.17.0-3.fc32.x86_64.rpm \
xen-licenses-4.17.0-3.fc32.x86_64.rpm \
xen-runtime-4.17.0-3.fc32.x86_64.rpm \
grub2-common-2.06-1.fc32.noarch.rpm \
grub2-pc-modules-2.06-1.fc32.noarch.rpm \
grub2-pc-2.06-1.fc32.x86_64.rpm \
grub2-tools-2.06-1.fc32.x86_64.rpm \
grub2-tools-extra-2.06-1.fc32.x86_64.rpm \
grub2-tools-minimal-2.06-1.fc32.x86_64.rpm
Invoke sudo grub2-install /dev/sdX, where X is the letter representing the
disk with /boot partition.
Additionally, you will have to download SINIT ACM and place it in /boot
partition/directory so that GRUB will be able to pick it up. Note it is only
necessary if your firmware/BIOS does not include/place SINIT ACM in the
Intel TXT region. You may obtain all SINIT ACMs as described
here (https://github.com/QubesOS/qubes-antievilmaid/blob/7561a4d724b9b0df8ba48d8f2735d3754961f87b/README#L177).
Copy the SINIT ACM suitable for your platform to /boot directory. In the
case of Dell OptiPlex it will be SNB_IVB_SINIT_20190708_PW.bin.
Install Qubes AEM packages with the following command because Qubes OS 4.2
lacks AEM packages:
qubes-dom0-update --enablerepo=qubes-dom0-current-testing anti-evil-maid
Enter the SeaBIOS TPM menu (hotkey t) and choose the clear TPM option.
Then activate and enable the TPM by selecting the appropriate options. If in
any case you are using proprietary firmware, clear the TPM and then enable
and activate it in the firmware setup application.
Follow the steps in set up TPM for AEM (https://github.com/QubesOS/qubes-antievilmaid/blob/7561a4d724b9b0df8ba48d8f2735d3754961f87b/README#L147).
The anti-evil-maid noscript may not work with LUKS2 in its current state, so
make a fix according to this Pull Request (https://github.com/QubesOS/qubes-antievilmaid/pull/41/files)
if needed.
Now it is possible to setup Qubes OS AEM device (https://github.com/QubesOS/qubes-antievilmaid/blob/7561a4d724b9b0df8ba48d8f2735d3754961f87b/README#L202).
This will create the AEM entry in Qubes GRUB, but this entry is using tboot.
You will need to edit the grub configuration file (/boot/grub2/grub.cfg)
by copying the standard Qubes OS entry (without AEM) and adding:
slaunch
slaunch_module /
before the multiboot2 directive, which loads Xen Hypervisor. Name the
entry differently, e.g. Qubes OS with TrenchBoot AEM. Also, you will need
to copy the AEM parameters for the Linux kernel: e.g.:
aem.uuid=38474da6-7b2d-410d-95e6-8683005fb23f rd.luks.key=/tmp/aem-keyfile rd.luks.crypttab=no
has been put into TrenchBoot SDK documentation (https://github.com/TrenchBoot/trenchboot-sdk/blob/3d56ca7b27bb038629fd838819a1050006725a1e/Documentation/build_qubes_packages.md).
Follow the instructions in the file to build the TrenchBoot AEM packages.
Installing Xen and GRUB packages
The following process was carried out and tested on
Qubes OS 4.2 (https://openqa.qubes-os.org/tests/55506#downloads).
In order to install the packages one has to send the Xen and GRUB RPMs to the
Dom0. Please note that moving any external files or data to Dom0 is potentially
dangerous. Ensure that your environment is safe and the RPMs have the right
checksums after copying them to Dom0. If you don’t know how to copy files to
Dom0, refer to the Qubes OS documentation (https://www.qubes-os.org/doc/how-to-copy-from-dom0/#copying-to-dom0).
Even before installing packages, it is required to enable the
current-testing repository to avoid the need to install additional
dependencies:
sudo qubes-dom0-update --enablerepo=qubes-dom0-current-testing
If the RPMs are inside Dom0, install them with the following command
(assuming you downloaded all of them to one directory):
sudo dnf update \
python3-xen-4.17.0-3.fc32.x86_64.rpm \
xen-4.17.0-3.fc32.x86_64.rpm \
xen-hypervisor-4.17.0-3.fc32.x86_64.rpm \
xen-libs-4.17.0-3.fc32.x86_64.rpm \
xen-licenses-4.17.0-3.fc32.x86_64.rpm \
xen-runtime-4.17.0-3.fc32.x86_64.rpm \
grub2-common-2.06-1.fc32.noarch.rpm \
grub2-pc-modules-2.06-1.fc32.noarch.rpm \
grub2-pc-2.06-1.fc32.x86_64.rpm \
grub2-tools-2.06-1.fc32.x86_64.rpm \
grub2-tools-extra-2.06-1.fc32.x86_64.rpm \
grub2-tools-minimal-2.06-1.fc32.x86_64.rpm
Invoke sudo grub2-install /dev/sdX, where X is the letter representing the
disk with /boot partition.
Additionally, you will have to download SINIT ACM and place it in /boot
partition/directory so that GRUB will be able to pick it up. Note it is only
necessary if your firmware/BIOS does not include/place SINIT ACM in the
Intel TXT region. You may obtain all SINIT ACMs as described
here (https://github.com/QubesOS/qubes-antievilmaid/blob/7561a4d724b9b0df8ba48d8f2735d3754961f87b/README#L177).
Copy the SINIT ACM suitable for your platform to /boot directory. In the
case of Dell OptiPlex it will be SNB_IVB_SINIT_20190708_PW.bin.
Install Qubes AEM packages with the following command because Qubes OS 4.2
lacks AEM packages:
qubes-dom0-update --enablerepo=qubes-dom0-current-testing anti-evil-maid
Enter the SeaBIOS TPM menu (hotkey t) and choose the clear TPM option.
Then activate and enable the TPM by selecting the appropriate options. If in
any case you are using proprietary firmware, clear the TPM and then enable
and activate it in the firmware setup application.
Follow the steps in set up TPM for AEM (https://github.com/QubesOS/qubes-antievilmaid/blob/7561a4d724b9b0df8ba48d8f2735d3754961f87b/README#L147).
The anti-evil-maid noscript may not work with LUKS2 in its current state, so
make a fix according to this Pull Request (https://github.com/QubesOS/qubes-antievilmaid/pull/41/files)
if needed.
Now it is possible to setup Qubes OS AEM device (https://github.com/QubesOS/qubes-antievilmaid/blob/7561a4d724b9b0df8ba48d8f2735d3754961f87b/README#L202).
This will create the AEM entry in Qubes GRUB, but this entry is using tboot.
You will need to edit the grub configuration file (/boot/grub2/grub.cfg)
by copying the standard Qubes OS entry (without AEM) and adding:
slaunch
slaunch_module /
before the multiboot2 directive, which loads Xen Hypervisor. Name the
entry differently, e.g. Qubes OS with TrenchBoot AEM. Also, you will need
to copy the AEM parameters for the Linux kernel: e.g.:
aem.uuid=38474da6-7b2d-410d-95e6-8683005fb23f rd.luks.key=/tmp/aem-keyfile rd.luks.crypttab=no