(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
We are still working on automating this step, so please bear with the
manual file edition for now.
Example GRUB entry:
menuentry 'Qubes, with TrenchBoot AEM' --class qubes --class gnu-linux --class gnu --class os --class xen $menuentry_id_option 'xen-gnulinux-simple-/dev/mapper/qubes_dom0-root' {
insmod part_msdos
insmod ext2
set root='hd0,msdos1'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos1 --hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1 --hint='hd0,msdos1' 38474da6-7b2d-410d-95e6-8683005fb23f
else
search --no-floppy --fs-uuid --set=root 38474da6-7b2d-410d-95e6-8683005fb23f
fi
echo 'Loading Xen 4.17.0 ...'
if [ "$grub_platform" = "pc" -o "$grub_platform" = "" ]; then
xen_rm_opts=
else
xen_rm_opts="no-real-mode edd=off"
fi
slaunch
slaunch_module /SNB_IVB_SINIT_20190708_PW.bin
multiboot2 /xen-4.17.0.gz placeholder console=none dom0_mem=min:1024M dom0_mem=max:4096M ucode=scan smt=off gnttab_max_frames=2048 gnttab_max_maptrack_frames=4096 ${xen_rm_opts}
echo 'Loading Linux 5.15.81-1.fc32.qubes.x86_64 ...'
module /vmlinuz-5.15.81-1.fc32.qubes.x86_64 placeholder root=/dev/mapper/qubes_dom0-root ro rd.luks.uuid=luks-f1f850fa-59bf-4911-8256-4986c485e112 rd.lvm.lv=qubes_dom0/root rd.lvm.lv=qubes_dom0/swap i915.alpha_support=1 rd.driver.pre=btrfs rhgb quiet console=ttyS0,115200 aem.uuid=38474da6-7b2d-410d-95e6-8683005fb23f rd.luks.key=/tmp/aem-keyfile rd.luks.crypttab=no
echo 'Loading initial ramdisk ...'
module2 --nounzip /initramfs-5.15.81-1.fc32.qubes.x86_64.img
}
You may put the above entry to /etc/grub.d/40_custom to avoid the removal of
the TrenchBoot AEM entry in case grub2-mkconfig will be called to overwrite
grub.cfg. Please note such a workaround will not allow for automatic Xen,
Linux, and initrd updates which may include security fixes. Making the
grub.cfg seamless for TrenchBoot is still in progress.
Verifying TrenchBoot AEM for Qubes OS
The moment of truth has come. If the installation has been performed
successfully, it is time to try out the TXT launch. So reboot the platform and
choose the newly created entry with TrenchBoot. If it succeeds, you should get
a TPM SRK and LUKS password prompts.
After the system boots, one may check if DRTM PCRs (17 and 18, 19 is not used
by TrenchBoot for now) have been populated:
cat /sys/class/tpm/tpm0/pcrs
PCR-00: 3A 3F 78 0F 11 A4 B4 99 69 FC AA 80 CD 6E 39 57 C3 3B 22 75
PCR-01: 4D E4 B0 42 71 50 E4 B1 DE C0 D7 F1 A0 29 A2 65 11 30 72 FD
PCR-02: CE EA EC 0A 01 D5 7B A3 55 5A 4C 02 59 4A EE A1 C9 41 78 FB
PCR-03: 3A 3F 78 0F 11 A4 B4 99 69 FC AA 80 CD 6E 39 57 C3 3B 22 75
PCR-04: 01 7A 3D E8 2F 4A 1B 77 FC 33 A9 03 FE F6 AD 27 EE 92 BE 04
PCR-05: BF 4E 38 B0 A7 7A 7A 4D 1A A9 B5 0F 59 D8 E5 F7 A6 46 8E 48
PCR-06: 3A 3F 78 0F 11 A4 B4 99 69 FC AA 80 CD 6E 39 57 C3 3B 22 75
PCR-07: 3A 3F 78 0F 11 A4 B4 99 69 FC AA 80 CD 6E 39 57 C3 3B 22 75
PCR-08: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
PCR-09: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
PCR-10: 9A 51 66 4D EB 1C B9 72 91 87 59 C4 89 AC 9A FF 7F 10 BF B3
PCR-11: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
PCR-12: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
PCR-13: 10 78 D0 16 8C 85 85 3A 7E 0A A1 D7 56 02 A7 05 D4 7F 22 64
PCR-14: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
PCR-15: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
PCR-16: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
PCR-17: 2A C9 64 F2 E2 96 50 B3 1D B7 2F 77 C4 7C A6 5D AA C8 4E E7
PCR-18: 84 4D D5 8D 95 EB 96 F6 CE 92 51 9C FD E2 33 45 71 C3 87 92
PCR-19: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
manual file edition for now.
Example GRUB entry:
menuentry 'Qubes, with TrenchBoot AEM' --class qubes --class gnu-linux --class gnu --class os --class xen $menuentry_id_option 'xen-gnulinux-simple-/dev/mapper/qubes_dom0-root' {
insmod part_msdos
insmod ext2
set root='hd0,msdos1'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos1 --hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1 --hint='hd0,msdos1' 38474da6-7b2d-410d-95e6-8683005fb23f
else
search --no-floppy --fs-uuid --set=root 38474da6-7b2d-410d-95e6-8683005fb23f
fi
echo 'Loading Xen 4.17.0 ...'
if [ "$grub_platform" = "pc" -o "$grub_platform" = "" ]; then
xen_rm_opts=
else
xen_rm_opts="no-real-mode edd=off"
fi
slaunch
slaunch_module /SNB_IVB_SINIT_20190708_PW.bin
multiboot2 /xen-4.17.0.gz placeholder console=none dom0_mem=min:1024M dom0_mem=max:4096M ucode=scan smt=off gnttab_max_frames=2048 gnttab_max_maptrack_frames=4096 ${xen_rm_opts}
echo 'Loading Linux 5.15.81-1.fc32.qubes.x86_64 ...'
module /vmlinuz-5.15.81-1.fc32.qubes.x86_64 placeholder root=/dev/mapper/qubes_dom0-root ro rd.luks.uuid=luks-f1f850fa-59bf-4911-8256-4986c485e112 rd.lvm.lv=qubes_dom0/root rd.lvm.lv=qubes_dom0/swap i915.alpha_support=1 rd.driver.pre=btrfs rhgb quiet console=ttyS0,115200 aem.uuid=38474da6-7b2d-410d-95e6-8683005fb23f rd.luks.key=/tmp/aem-keyfile rd.luks.crypttab=no
echo 'Loading initial ramdisk ...'
module2 --nounzip /initramfs-5.15.81-1.fc32.qubes.x86_64.img
}
You may put the above entry to /etc/grub.d/40_custom to avoid the removal of
the TrenchBoot AEM entry in case grub2-mkconfig will be called to overwrite
grub.cfg. Please note such a workaround will not allow for automatic Xen,
Linux, and initrd updates which may include security fixes. Making the
grub.cfg seamless for TrenchBoot is still in progress.
Verifying TrenchBoot AEM for Qubes OS
The moment of truth has come. If the installation has been performed
successfully, it is time to try out the TXT launch. So reboot the platform and
choose the newly created entry with TrenchBoot. If it succeeds, you should get
a TPM SRK and LUKS password prompts.
After the system boots, one may check if DRTM PCRs (17 and 18, 19 is not used
by TrenchBoot for now) have been populated:
cat /sys/class/tpm/tpm0/pcrs
PCR-00: 3A 3F 78 0F 11 A4 B4 99 69 FC AA 80 CD 6E 39 57 C3 3B 22 75
PCR-01: 4D E4 B0 42 71 50 E4 B1 DE C0 D7 F1 A0 29 A2 65 11 30 72 FD
PCR-02: CE EA EC 0A 01 D5 7B A3 55 5A 4C 02 59 4A EE A1 C9 41 78 FB
PCR-03: 3A 3F 78 0F 11 A4 B4 99 69 FC AA 80 CD 6E 39 57 C3 3B 22 75
PCR-04: 01 7A 3D E8 2F 4A 1B 77 FC 33 A9 03 FE F6 AD 27 EE 92 BE 04
PCR-05: BF 4E 38 B0 A7 7A 7A 4D 1A A9 B5 0F 59 D8 E5 F7 A6 46 8E 48
PCR-06: 3A 3F 78 0F 11 A4 B4 99 69 FC AA 80 CD 6E 39 57 C3 3B 22 75
PCR-07: 3A 3F 78 0F 11 A4 B4 99 69 FC AA 80 CD 6E 39 57 C3 3B 22 75
PCR-08: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
PCR-09: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
PCR-10: 9A 51 66 4D EB 1C B9 72 91 87 59 C4 89 AC 9A FF 7F 10 BF B3
PCR-11: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
PCR-12: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
PCR-13: 10 78 D0 16 8C 85 85 3A 7E 0A A1 D7 56 02 A7 05 D4 7F 22 64
PCR-14: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
PCR-15: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
PCR-16: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
PCR-17: 2A C9 64 F2 E2 96 50 B3 1D B7 2F 77 C4 7C A6 5D AA C8 4E E7
PCR-18: 84 4D D5 8D 95 EB 96 F6 CE 92 51 9C FD E2 33 45 71 C3 87 92
PCR-19: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
PCR-20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
PCR-21: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
PCR-22: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
PCR-23: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Note that AEM will fail to unseal secrets as the PCRs are changed. To re-seal
the secret you will have to perform the following steps after a successful boot
with TrenchBoot:
Re-seal the secret sudo anti-evil-maid-seal "".
Reboot the machine and notice that the anti-evil-maid service no longer
fails during boot. The secret should be displayed on the screen, indicating
the machine boots correctly and unseals the secret.
Summary
It has been shown that TrenchBoot can be integrated to perform DRTM secure
launch of Qubes OS in place of old tboot. Moreover, TrenchBoot is more
extensible to other platforms like AMD. In the future, Anti Evil Maid will be
available on both Intel and AMD platforms with both TPM 1.2 and TPM 2.0, thanks
to TrenchBoot (which seemed to not be possible with tboot only).
If you think we can help in improving the security of your firmware or you are
looking for someone who can boost your product by leveraging advanced features
of used hardware platform, feel free to book a call with us (https://calendly.com/3mdeb/consulting-remote-meeting)
or drop us email to contact3mdebcom. If you are interested in
similar content, feel free to sign up to our newsletter (https://newsletter.3mdeb.com/subnoscription/PW6XnCeK6)
PCR-21: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
PCR-22: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
PCR-23: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Note that AEM will fail to unseal secrets as the PCRs are changed. To re-seal
the secret you will have to perform the following steps after a successful boot
with TrenchBoot:
Re-seal the secret sudo anti-evil-maid-seal "".
Reboot the machine and notice that the anti-evil-maid service no longer
fails during boot. The secret should be displayed on the screen, indicating
the machine boots correctly and unseals the secret.
Summary
It has been shown that TrenchBoot can be integrated to perform DRTM secure
launch of Qubes OS in place of old tboot. Moreover, TrenchBoot is more
extensible to other platforms like AMD. In the future, Anti Evil Maid will be
available on both Intel and AMD platforms with both TPM 1.2 and TPM 2.0, thanks
to TrenchBoot (which seemed to not be possible with tboot only).
If you think we can help in improving the security of your firmware or you are
looking for someone who can boost your product by leveraging advanced features
of used hardware platform, feel free to book a call with us (https://calendly.com/3mdeb/consulting-remote-meeting)
or drop us email to contact3mdebcom. If you are interested in
similar content, feel free to sign up to our newsletter (https://newsletter.3mdeb.com/subnoscription/PW6XnCeK6)
Qubes OS 4.1.2-rc1 has been released!
https://www.qubes-os.org/news/2023/02/09/qubes-4-1-2-rc1/
We’re pleased to announce the first release candidate (https://www.qubes-os.org/#what-is-a-release-candidate) for Qubes 4.1.2! This patch release (https://www.qubes-os.org/#what-is-a-patch-release) aims to consolidate all the security patches, bug fixes, and upstream template OS upgrades that have occurred since prior Qubes 4.1 releases. Our goal is to provide a secure and convenient way for users to install (or reinstall) the latest stable Qubes release with an up-to-date ISO.
Qubes 4.1.2-rc1 is available on the downloads (https://www.qubes-os.org/downloads/) page.
What’s new in Qubes 4.1.2?
Qubes 4.1.2-rc1 includes numerous updates over the initial 4.1.0 release, in particular:
All 4.1 dom0 updates to date
Fedora 37 template
USB keyboard support in the installer (#7674 (https://github.com/QubesOS/qubes-issues/issues/7674))
kernel-latest available as a boot option when starting the installer (#5900 (https://github.com/QubesOS/qubes-issues/issues/5900))
Testing Qubes 4.1.2-rc1
If you’re willing to test (https://www.qubes-os.org/doc/testing/) this release candidate, you can help to improve the eventual stable release by reporting any bugs you encounter (https://www.qubes-os.org/doc/issue-tracking/). We strongly encourage experienced users to join the testing team (https://forum.qubes-os.org/t/joining-the-testing-team/5190)!
Existing Qubes 4.1 users
If you’re not interested in testing this release candidate, and you’re already using Qubes 4.1, then you should simply update normally (https://www.qubes-os.org/doc/how-to-update/) (which includes upgrading any EOL templates (https://www.qubes-os.org/doc/how-to-update/#upgrading-to-avoid-eol) you might have) in order to make your system essentially equivalent to this patch release. No special action is required on your part.
Release candidate planning
If no significant bugs are discovered in 4.1.2-rc1, we expect to announce the stable release of 4.1.2 in two to three weeks.
What is a release candidate?
A release candidate (RC) is a software build that has the potential to become a stable release, unless significant bugs are discovered in testing. Release candidates are intended for more advanced (or adventurous!) users who are comfortable testing early versions of software that are potentially buggier than stable releases. You can read more about Qubes OS supported releases (https://www.qubes-os.org/doc/supported-releases/) and the version scheme (https://www.qubes-os.org/doc/version-scheme/) in our documentation.
What is a patch release?
The Qubes OS Project uses the semantic versioning (https://semver.org/) standard. Version numbers are written as ... Hence, we refer to releases that increment the third number as “patch releases.” A patch release does not designate a separate, new major or minor release of Qubes OS. Rather, it designates its respective major or minor release (in this case, 4.1) inclusive of all updates up to a certain point. (See supported releases (https://www.qubes-os.org/doc/supported-releases/) for a comprehensive list of major and minor releases.) Installing any prior Qubes 4.1 release and fully updating (https://www.qubes-os.org/doc/how-to-update/) it results in essentially the same system as installing Qubes 4.1.2. You can learn more about how Qubes release versioning works in the version scheme (https://www.qubes-os.org/doc/version-scheme/) documentation.
https://www.qubes-os.org/news/2023/02/09/qubes-4-1-2-rc1/
We’re pleased to announce the first release candidate (https://www.qubes-os.org/#what-is-a-release-candidate) for Qubes 4.1.2! This patch release (https://www.qubes-os.org/#what-is-a-patch-release) aims to consolidate all the security patches, bug fixes, and upstream template OS upgrades that have occurred since prior Qubes 4.1 releases. Our goal is to provide a secure and convenient way for users to install (or reinstall) the latest stable Qubes release with an up-to-date ISO.
Qubes 4.1.2-rc1 is available on the downloads (https://www.qubes-os.org/downloads/) page.
What’s new in Qubes 4.1.2?
Qubes 4.1.2-rc1 includes numerous updates over the initial 4.1.0 release, in particular:
All 4.1 dom0 updates to date
Fedora 37 template
USB keyboard support in the installer (#7674 (https://github.com/QubesOS/qubes-issues/issues/7674))
kernel-latest available as a boot option when starting the installer (#5900 (https://github.com/QubesOS/qubes-issues/issues/5900))
Testing Qubes 4.1.2-rc1
If you’re willing to test (https://www.qubes-os.org/doc/testing/) this release candidate, you can help to improve the eventual stable release by reporting any bugs you encounter (https://www.qubes-os.org/doc/issue-tracking/). We strongly encourage experienced users to join the testing team (https://forum.qubes-os.org/t/joining-the-testing-team/5190)!
Existing Qubes 4.1 users
If you’re not interested in testing this release candidate, and you’re already using Qubes 4.1, then you should simply update normally (https://www.qubes-os.org/doc/how-to-update/) (which includes upgrading any EOL templates (https://www.qubes-os.org/doc/how-to-update/#upgrading-to-avoid-eol) you might have) in order to make your system essentially equivalent to this patch release. No special action is required on your part.
Release candidate planning
If no significant bugs are discovered in 4.1.2-rc1, we expect to announce the stable release of 4.1.2 in two to three weeks.
What is a release candidate?
A release candidate (RC) is a software build that has the potential to become a stable release, unless significant bugs are discovered in testing. Release candidates are intended for more advanced (or adventurous!) users who are comfortable testing early versions of software that are potentially buggier than stable releases. You can read more about Qubes OS supported releases (https://www.qubes-os.org/doc/supported-releases/) and the version scheme (https://www.qubes-os.org/doc/version-scheme/) in our documentation.
What is a patch release?
The Qubes OS Project uses the semantic versioning (https://semver.org/) standard. Version numbers are written as ... Hence, we refer to releases that increment the third number as “patch releases.” A patch release does not designate a separate, new major or minor release of Qubes OS. Rather, it designates its respective major or minor release (in this case, 4.1) inclusive of all updates up to a certain point. (See supported releases (https://www.qubes-os.org/doc/supported-releases/) for a comprehensive list of major and minor releases.) Installing any prior Qubes 4.1 release and fully updating (https://www.qubes-os.org/doc/how-to-update/) it results in essentially the same system as installing Qubes 4.1.2. You can learn more about how Qubes release versioning works in the version scheme (https://www.qubes-os.org/doc/version-scheme/) documentation.
❤8
XSAs released on 2023-02-14
https://www.qubes-os.org/news/2023/02/15/xsas-released-on-2023-02-14/
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-426 (SMT is disabled in Qubes OS by default)
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/02/15/xsas-released-on-2023-02-14/
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-426 (SMT is disabled in Qubes OS by default)
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.
👍2
Qubes Canary 034
https://www.qubes-os.org/news/2023/03/02/canary-034/
We have published a new Qubes canary (https://www.qubes-os.org/security/canary/). The text of this canary is reproduced below. This canary and its accompanying cryptographic signatures will always be available in the Qubes security pack (qubes-secpack) (https://www.qubes-os.org/security/pack/).
---===[ Qubes Canary 034 ]===---
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] 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
https://www.qubes-os.org/news/2023/03/02/canary-034/
We have published a new Qubes canary (https://www.qubes-os.org/security/canary/). The text of this canary is reproduced below. This canary and its accompanying cryptographic signatures will always be available in the Qubes security pack (qubes-secpack) (https://www.qubes-os.org/security/pack/).
---===[ Qubes Canary 034 ]===---
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] 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/
[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/
Fedora 37 templates available
https://www.qubes-os.org/news/2023/03/03/fedora-37-templates-available/
New Fedora 37 templates are now available! We provide fresh Fedora 37 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).
As a reminder, Fedora 35 has reached EOL (https://www.qubes-os.org/news/2022/12/08/fedora-35-reaches-eol-on-2022-12-13/). If you have not already done so, we strongly recommend that you upgrade (https://www.qubes-os.org/doc/templates/fedora/#upgrading) all Fedora 35
templates and standalones to a supported template release (https://www.qubes-os.org/doc/supported-releases/#templates) immediately.
Please note that no user action is required regarding the OS version in dom0 (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/2023/03/03/fedora-37-templates-available/
New Fedora 37 templates are now available! We provide fresh Fedora 37 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).
As a reminder, Fedora 35 has reached EOL (https://www.qubes-os.org/news/2022/12/08/fedora-35-reaches-eol-on-2022-12-13/). If you have not already done so, we strongly recommend that you upgrade (https://www.qubes-os.org/doc/templates/fedora/#upgrading) all Fedora 35
templates and standalones to a supported template release (https://www.qubes-os.org/doc/supported-releases/#templates) immediately.
Please note that no user action is required regarding the OS version in dom0 (see our note on dom0 and EOL (https://www.qubes-os.org/doc/supported-releases/#note-on-dom0-and-eol)).
👍1
Qubes OS 4.1.2-rc2 has been released!
https://www.qubes-os.org/news/2023/03/06/qubes-4-1-2-rc2/
We’re pleased to announce the second release candidate (https://www.qubes-os.org/#what-is-a-release-candidate) for Qubes 4.1.2! This patch release (https://www.qubes-os.org/#what-is-a-patch-release) aims to consolidate all the security patches, bug fixes, and upstream template OS upgrades that have occurred since prior Qubes 4.1 releases. Our goal is to provide a secure and convenient way for users to install (or reinstall) the latest stable Qubes release with an up-to-date ISO.
Qubes 4.1.2-rc2 is available on the downloads (https://www.qubes-os.org/downloads/) page.
What’s new in Qubes 4.1.2?
Qubes 4.1.2-rc2 includes numerous updates over the initial 4.1.0 release, in particular:
All 4.1 dom0 updates to date
Fedora 37 template
USB keyboard support in the installer (#7674 (https://github.com/QubesOS/qubes-issues/issues/7674))
kernel-latest available as a boot option when starting the installer (#5900 (https://github.com/QubesOS/qubes-issues/issues/5900))
Fixes for bugs discovered in 4.1.2-rc1
Testing Qubes 4.1.2-rc2
If you’re willing to test (https://www.qubes-os.org/doc/testing/) this release candidate, you can help to improve the eventual stable release by reporting any bugs you encounter (https://www.qubes-os.org/doc/issue-tracking/). We strongly encourage experienced users to join the testing team (https://forum.qubes-os.org/t/joining-the-testing-team/5190)!
Thank you to everyone who tested and reported bugs in 4.1.2-rc1!
Existing Qubes 4.1 users
If you’re not interested in testing this release candidate, and you’re already using Qubes 4.1, then you should simply update normally (https://www.qubes-os.org/doc/how-to-update/) (which includes upgrading any EOL templates (https://www.qubes-os.org/doc/how-to-update/#upgrading-to-avoid-eol) you might have) in order to make your system essentially equivalent to this patch release. No special action is required on your part.
When is the stable release?
If no significant bugs are discovered in 4.1.2-rc2, we expect to announce the stable release of 4.1.2 in approximately one week.
What is a release candidate?
A release candidate (RC) is a software build that has the potential to become a stable release, unless significant bugs are discovered in testing. Release candidates are intended for more advanced (or adventurous!) users who are comfortable testing early versions of software that are potentially buggier than stable releases. You can read more about Qubes OS supported releases (https://www.qubes-os.org/doc/supported-releases/) and the version scheme (https://www.qubes-os.org/doc/version-scheme/) in our documentation.
What is a patch release?
The Qubes OS Project uses the semantic versioning (https://semver.org/) standard. Version numbers are written as ... Hence, we refer to releases that increment the third number as “patch releases.” A patch release does not designate a separate, new major or minor release of Qubes OS. Rather, it designates its respective major or minor release (in this case, 4.1) inclusive of all updates up to a certain point. (See supported releases (https://www.qubes-os.org/doc/supported-releases/) for a comprehensive list of major and minor releases.) Installing any prior Qubes 4.1 release and fully updating (https://www.qubes-os.org/doc/how-to-update/) it results in essentially the same system as installing Qubes 4.1.2. You can learn more about how Qubes release versioning works in the version scheme (https://www.qubes-os.org/doc/version-scheme/) documentation.
https://www.qubes-os.org/news/2023/03/06/qubes-4-1-2-rc2/
We’re pleased to announce the second release candidate (https://www.qubes-os.org/#what-is-a-release-candidate) for Qubes 4.1.2! This patch release (https://www.qubes-os.org/#what-is-a-patch-release) aims to consolidate all the security patches, bug fixes, and upstream template OS upgrades that have occurred since prior Qubes 4.1 releases. Our goal is to provide a secure and convenient way for users to install (or reinstall) the latest stable Qubes release with an up-to-date ISO.
Qubes 4.1.2-rc2 is available on the downloads (https://www.qubes-os.org/downloads/) page.
What’s new in Qubes 4.1.2?
Qubes 4.1.2-rc2 includes numerous updates over the initial 4.1.0 release, in particular:
All 4.1 dom0 updates to date
Fedora 37 template
USB keyboard support in the installer (#7674 (https://github.com/QubesOS/qubes-issues/issues/7674))
kernel-latest available as a boot option when starting the installer (#5900 (https://github.com/QubesOS/qubes-issues/issues/5900))
Fixes for bugs discovered in 4.1.2-rc1
Testing Qubes 4.1.2-rc2
If you’re willing to test (https://www.qubes-os.org/doc/testing/) this release candidate, you can help to improve the eventual stable release by reporting any bugs you encounter (https://www.qubes-os.org/doc/issue-tracking/). We strongly encourage experienced users to join the testing team (https://forum.qubes-os.org/t/joining-the-testing-team/5190)!
Thank you to everyone who tested and reported bugs in 4.1.2-rc1!
Existing Qubes 4.1 users
If you’re not interested in testing this release candidate, and you’re already using Qubes 4.1, then you should simply update normally (https://www.qubes-os.org/doc/how-to-update/) (which includes upgrading any EOL templates (https://www.qubes-os.org/doc/how-to-update/#upgrading-to-avoid-eol) you might have) in order to make your system essentially equivalent to this patch release. No special action is required on your part.
When is the stable release?
If no significant bugs are discovered in 4.1.2-rc2, we expect to announce the stable release of 4.1.2 in approximately one week.
What is a release candidate?
A release candidate (RC) is a software build that has the potential to become a stable release, unless significant bugs are discovered in testing. Release candidates are intended for more advanced (or adventurous!) users who are comfortable testing early versions of software that are potentially buggier than stable releases. You can read more about Qubes OS supported releases (https://www.qubes-os.org/doc/supported-releases/) and the version scheme (https://www.qubes-os.org/doc/version-scheme/) in our documentation.
What is a patch release?
The Qubes OS Project uses the semantic versioning (https://semver.org/) standard. Version numbers are written as ... Hence, we refer to releases that increment the third number as “patch releases.” A patch release does not designate a separate, new major or minor release of Qubes OS. Rather, it designates its respective major or minor release (in this case, 4.1) inclusive of all updates up to a certain point. (See supported releases (https://www.qubes-os.org/doc/supported-releases/) for a comprehensive list of major and minor releases.) Installing any prior Qubes 4.1 release and fully updating (https://www.qubes-os.org/doc/how-to-update/) it results in essentially the same system as installing Qubes 4.1.2. You can learn more about how Qubes release versioning works in the version scheme (https://www.qubes-os.org/doc/version-scheme/) documentation.
👍6
Qubes OS 4.1.2 has been released!
https://www.qubes-os.org/news/2023/03/15/qubes-4-1-2/
We’re pleased to announce the stable release of Qubes 4.1.2! This release aims to consolidate all the security patches, bug fixes, and upstream template OS upgrades that have occurred since the initial Qubes 4.1.0 release. Our goal is to provide a secure and convenient way for users to install (or reinstall) the latest stable Qubes release with an up-to-date ISO.
Qubes 4.1.2 is available on the downloads (https://www.qubes-os.org/downloads/) page.
Existing installations
If you are already using any version of Qubes 4.1 (including 4.1.0, 4.1.1, 4.1.2-rc1, and 4.1.2-rc2), then you should simply update normally (https://www.qubes-os.org/doc/how-to-update/) (which includes upgrading any EOL templates (https://www.qubes-os.org/doc/how-to-update/#upgrading-to-avoid-eol) you might have) in order to make your system effectively equivalent to this stable Qubes 4.1.2 release. No reinstallation or other special action is required.
New installations
If you would like to install Qubes OS for the first time or perform a clean reinstallation on an existing system, there has never been a better time to do so! Simply download (https://www.qubes-os.org/downloads/) the Qubes 4.1.2 ISO and follow our installation guide (https://www.qubes-os.org/doc/installation-guide/).
What’s new in Qubes 4.1.2?
Qubes 4.1.2 includes numerous updates over the initial 4.1.0 release, in particular:
All 4.1 dom0 updates to date
Fedora 37 template
USB keyboard support in the installer (#7674 (https://github.com/QubesOS/qubes-issues/issues/7674))
kernel-latest available as a boot option when starting the installer (#5900 (https://github.com/QubesOS/qubes-issues/issues/5900))
What is a patch release?
The Qubes OS Project uses the semantic versioning (https://semver.org/) standard. Version numbers are written as ... Hence, we refer to releases that increment the third number as “patch releases.” A patch release does not designate a separate, new major or minor release of Qubes OS. Rather, it designates its respective major or minor release (in this case, 4.1) inclusive of all updates up to a certain point. (See supported releases (https://www.qubes-os.org/doc/supported-releases/) for a comprehensive list of major and minor releases.) Installing any prior Qubes 4.1 release and fully updating (https://www.qubes-os.org/doc/how-to-update/) it results in essentially the same system as installing Qubes 4.1.2. You can learn more about how Qubes release versioning works in the version scheme (https://www.qubes-os.org/doc/version-scheme/) documentation.
Reminder: Qubes 4.0 has reached end-of-life
Qubes 4.0 reached EOL (end-of-life) on 2022-08-04 (https://www.qubes-os.org/news/2022/07/04/qubes-os-4-0-eol-on-2022-08-04/). If you’re still using Qubes 4.0, we strongly recommend upgrading to Qubes 4.1.
https://www.qubes-os.org/news/2023/03/15/qubes-4-1-2/
We’re pleased to announce the stable release of Qubes 4.1.2! This release aims to consolidate all the security patches, bug fixes, and upstream template OS upgrades that have occurred since the initial Qubes 4.1.0 release. Our goal is to provide a secure and convenient way for users to install (or reinstall) the latest stable Qubes release with an up-to-date ISO.
Qubes 4.1.2 is available on the downloads (https://www.qubes-os.org/downloads/) page.
Existing installations
If you are already using any version of Qubes 4.1 (including 4.1.0, 4.1.1, 4.1.2-rc1, and 4.1.2-rc2), then you should simply update normally (https://www.qubes-os.org/doc/how-to-update/) (which includes upgrading any EOL templates (https://www.qubes-os.org/doc/how-to-update/#upgrading-to-avoid-eol) you might have) in order to make your system effectively equivalent to this stable Qubes 4.1.2 release. No reinstallation or other special action is required.
New installations
If you would like to install Qubes OS for the first time or perform a clean reinstallation on an existing system, there has never been a better time to do so! Simply download (https://www.qubes-os.org/downloads/) the Qubes 4.1.2 ISO and follow our installation guide (https://www.qubes-os.org/doc/installation-guide/).
What’s new in Qubes 4.1.2?
Qubes 4.1.2 includes numerous updates over the initial 4.1.0 release, in particular:
All 4.1 dom0 updates to date
Fedora 37 template
USB keyboard support in the installer (#7674 (https://github.com/QubesOS/qubes-issues/issues/7674))
kernel-latest available as a boot option when starting the installer (#5900 (https://github.com/QubesOS/qubes-issues/issues/5900))
What is a patch release?
The Qubes OS Project uses the semantic versioning (https://semver.org/) standard. Version numbers are written as ... Hence, we refer to releases that increment the third number as “patch releases.” A patch release does not designate a separate, new major or minor release of Qubes OS. Rather, it designates its respective major or minor release (in this case, 4.1) inclusive of all updates up to a certain point. (See supported releases (https://www.qubes-os.org/doc/supported-releases/) for a comprehensive list of major and minor releases.) Installing any prior Qubes 4.1 release and fully updating (https://www.qubes-os.org/doc/how-to-update/) it results in essentially the same system as installing Qubes 4.1.2. You can learn more about how Qubes release versioning works in the version scheme (https://www.qubes-os.org/doc/version-scheme/) documentation.
Reminder: Qubes 4.0 has reached end-of-life
Qubes 4.0 reached EOL (end-of-life) on 2022-08-04 (https://www.qubes-os.org/news/2022/07/04/qubes-os-4-0-eol-on-2022-08-04/). If you’re still using Qubes 4.0, we strongly recommend upgrading to Qubes 4.1.
🔥5❤2👍1
XSAs released on 2023-04-25
https://www.qubes-os.org/news/2023/04/25/xsas-released-on-2023-04-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-430 (https://xenbits.xen.org/xsa/advisory-430.html)
Shadow paging is disabled in Qubes OS at build time.
Qubes OS 4.1 uses an unaffected version of Xen (4.14).
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/04/25/xsas-released-on-2023-04-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-430 (https://xenbits.xen.org/xsa/advisory-430.html)
Shadow paging is disabled in Qubes OS at build time.
Qubes OS 4.1 uses an unaffected version of Xen (4.14).
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👍2🙏1
The NovaCustom NV41 Series laptop is Qubes-certified!
https://www.qubes-os.org/news/2023/05/03/novacustom-nv41-series-qubes-certified/
It is our pleasure to announce that the NovaCustom NV41 Series (https://configurelaptop.eu/nv41-series/) laptop has become the fifth Qubes-certified computer (https://www.qubes-os.org/doc/certified-hardware/) for Qubes 4.X!
About the NovaCustom NV41 Series
https://www.qubes-os.org/news/2023/05/03/novacustom-nv41-series-qubes-certified/
It is our pleasure to announce that the NovaCustom NV41 Series (https://configurelaptop.eu/nv41-series/) laptop has become the fifth Qubes-certified computer (https://www.qubes-os.org/doc/certified-hardware/) for Qubes 4.X!
About the NovaCustom NV41 Series
❤2
The NV41 Series (https://configurelaptop.eu/nv41-series/) is a 14-inch laptop from NovaCustom (https://configurelaptop.eu/), a European vendor known for their highly customizable, Linux-friendly laptops. This 12th Generation Intel Core (Alder Lake) laptop comes with Dasharo coreboot open-source firmware, USB-C charging, the latest Intel Xe graphics, and up to 64 GB of memory.
Qubes-certified configurations
The following configuration options are certified for Qubes OS 4.X:
Processor:
Intel Core i5-1240P processor
Intel Core i7-1260P processor
Memory (Dual Channel):
2 x 16 GB Kingston DDR4 SODIMM 3200 MHz (32 GB total)
1 x 32 GB Kingston DDR4 SODIMM 3200 MHz (32 GB total)
2 x 32 GB Kingston DDR4 SODIMM 3200 MHz (64 GB total)
M.2 storage chip:
Samsung 980 SSD (all capacities)
Samsung 980 Pro SSD (all capacities)
Wi-Fi and Bluetooth:
Intel AX-200/201 Wi-Fi module 2976 Mbps, 802.11ax/Wi-Fi 6 + Bluetooth 5.2
Killer (Intel) Wireless-AX 1675x M.2 Wi-Fi module 802.11ax/Wi-Fi 6E + Bluetooth 5.3
Blob-free: Qualcomm Atheros QCNFA222 Wi-Fi 802.11a/b/g/n + Bluetooth 4.0
No Wi-Fi/Bluetooth chip
Notes on Wi-Fi and Bluetooth options
When viewed in a Linux environment with lspci, the “Killer (Intel) Wireless-AX 1675x M.2 Wi-Fi module 802.11ax/Wi-Fi 6E + Bluetooth 5.3” device displays the model number “AX210.” However, according to its Intel Ark entry (https://ark.intel.com/content/www/us/en/ark/products/211485/intel-killer-wifi-6e-ax1675-xw.html) (in the “Product Brief” file), they are actually the same Wi-Fi module.
Similarly, when viewed in a Linux environment with lspci, the “Blob-free: Qualcomm Atheros QCNFA222 Wi-Fi 802.11a/b/g/n + Bluetooth 4.0” device displays the model number “AR9462,” which seems to be just the Wi-Fi chip model number, whereas “QCNFA222” seems to be the model number of the whole device (which include Bluetooth). Meanwhile, the Bluetooth device presents itself as “IMC Networks Device 3487.”
The term “blob-free” is used in different ways. In practice, being “blob-free” generally does not mean that the device does not use any closed-source firmware “blobs.” Rather, it means that the device comes with firmware preinstalled so that it does not have to be loaded from the operating system. In theory, the preinstalled firmware could be open-source, but as far as we know, that is not the case with this particular Atheros Wi-Fi/Bluetooth module. (Qualcomm has published firmware source code in the past, but only for other device models, as far as we are aware.) Meanwhile, the Free Software Foundation (FSF) considers (https://www.gnu.org/philosophy/free-hardware-designs.en.html#boundary) unmodifiable preinstalled firmware to be part of the hardware, hence they regard such hardware as “blob-free” from a software perspective. While common usage of the term “blob-free” often follows the FSF’s interpretation, it is worthwhile for Qubes users who are concerned about closed-source firmware to understand the nuance.
Special note regarding the need for kernel-latest
Beginning with Qubes OS 4.1.2, the Qubes installer includes the kernel-latest package and allows users to select this kernel option from the GRUB menu when booting the installer. At the time of this announcement, kernel-latest is required for the NovaCustom NV41 Series to function properly. Therefore, all potential purchasers and users of this model should be aware that they will have to select a non-default option (Install Qubes OS RX using kernel-latest) from the GRUB menu when booting the installer. However, since Linux 6.1 has officially been promoted to being a long-term support (LTS) kernel, it will become the default kernel at some point, which means that the need for this non-default selection is only temporary.
What is Qubes-certified hardware?
Qubes-certified configurations
The following configuration options are certified for Qubes OS 4.X:
Processor:
Intel Core i5-1240P processor
Intel Core i7-1260P processor
Memory (Dual Channel):
2 x 16 GB Kingston DDR4 SODIMM 3200 MHz (32 GB total)
1 x 32 GB Kingston DDR4 SODIMM 3200 MHz (32 GB total)
2 x 32 GB Kingston DDR4 SODIMM 3200 MHz (64 GB total)
M.2 storage chip:
Samsung 980 SSD (all capacities)
Samsung 980 Pro SSD (all capacities)
Wi-Fi and Bluetooth:
Intel AX-200/201 Wi-Fi module 2976 Mbps, 802.11ax/Wi-Fi 6 + Bluetooth 5.2
Killer (Intel) Wireless-AX 1675x M.2 Wi-Fi module 802.11ax/Wi-Fi 6E + Bluetooth 5.3
Blob-free: Qualcomm Atheros QCNFA222 Wi-Fi 802.11a/b/g/n + Bluetooth 4.0
No Wi-Fi/Bluetooth chip
Notes on Wi-Fi and Bluetooth options
When viewed in a Linux environment with lspci, the “Killer (Intel) Wireless-AX 1675x M.2 Wi-Fi module 802.11ax/Wi-Fi 6E + Bluetooth 5.3” device displays the model number “AX210.” However, according to its Intel Ark entry (https://ark.intel.com/content/www/us/en/ark/products/211485/intel-killer-wifi-6e-ax1675-xw.html) (in the “Product Brief” file), they are actually the same Wi-Fi module.
Similarly, when viewed in a Linux environment with lspci, the “Blob-free: Qualcomm Atheros QCNFA222 Wi-Fi 802.11a/b/g/n + Bluetooth 4.0” device displays the model number “AR9462,” which seems to be just the Wi-Fi chip model number, whereas “QCNFA222” seems to be the model number of the whole device (which include Bluetooth). Meanwhile, the Bluetooth device presents itself as “IMC Networks Device 3487.”
The term “blob-free” is used in different ways. In practice, being “blob-free” generally does not mean that the device does not use any closed-source firmware “blobs.” Rather, it means that the device comes with firmware preinstalled so that it does not have to be loaded from the operating system. In theory, the preinstalled firmware could be open-source, but as far as we know, that is not the case with this particular Atheros Wi-Fi/Bluetooth module. (Qualcomm has published firmware source code in the past, but only for other device models, as far as we are aware.) Meanwhile, the Free Software Foundation (FSF) considers (https://www.gnu.org/philosophy/free-hardware-designs.en.html#boundary) unmodifiable preinstalled firmware to be part of the hardware, hence they regard such hardware as “blob-free” from a software perspective. While common usage of the term “blob-free” often follows the FSF’s interpretation, it is worthwhile for Qubes users who are concerned about closed-source firmware to understand the nuance.
Special note regarding the need for kernel-latest
Beginning with Qubes OS 4.1.2, the Qubes installer includes the kernel-latest package and allows users to select this kernel option from the GRUB menu when booting the installer. At the time of this announcement, kernel-latest is required for the NovaCustom NV41 Series to function properly. Therefore, all potential purchasers and users of this model should be aware that they will have to select a non-default option (Install Qubes OS RX using kernel-latest) from the GRUB menu when booting the installer. However, since Linux 6.1 has officially been promoted to being a long-term support (LTS) kernel, it will become the default kernel at some point, which means that the need for this non-default selection is only temporary.
What is Qubes-certified hardware?
❤5👍3