Hello here,
I just found this post about a feature that I was not aware of, and seems to result from a patch that is very specific to openSUSE, namely Trusted Boot:
https://lizards.opensuse.org/2016/05/18/highlights-of-yast-development-spri…
1) About Secure Boot
I have been using SecureBoot for a while, and here is my understanding of Secure Boot in openSUSE:
- the root of trust is the UEFI ;
- it does use the TPM for cryptographic measurements ;
- Shim in the EFI partition is the first component to check the signature of grub, then subsequently the chain continues from the kernel up to the modules.
It works pretty well, except that most distributions have an implementation flaw (e.g Ubuntu, Fedora): as long as /boot has not been encrypted, an attacker with physical access to the machine can alter the initrd, do nasty stuff (like hijacking the user encryption password) and then proceed with the boot execution normally.
I can confirm this flaw for sure as this is something that we have tested at my work.
In openSUSE, /boot is encrypted by default and Grub has been patched to prompt for decryption, so this is a good mitigation against these "evil maid attacks".
Overall, did I get it correctly ?
2) About Trusted boot
The documentation is sparse so I am confused on how it compares with the SecureBoot implementation above.
My understanding is that it's exactly the same, except that it's some kind of legacy support for Grub and legacy BIOS, without UEFI.
It's not clear here what's the root of trust: I guess this can only be Grub itself, storing measurements in the TPM.
Again, thank you for telling me if I am correct or wrong...
Following your feedback, it might be a good idea that I write some stuff in the wiki or/and my blog to clarify all this.
Thank you !
Best regards,
Jean-Christophe
--
To unsubscribe, e-mail: opensuse-security+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-security+owner(a)opensuse.org
This security update
https://lists.opensuse.org/opensuse-security-announce/2019-07/msg00052.html
addresses
Four new speculative execution information leak issues have been
identified in Intel CPUs. (bsc#1111331)
- CVE-2018-12126: Microarchitectural Store Buffer Data Sampling (MSBDS)
- CVE-2018-12127: Microarchitectural Fill Buffer Data Sampling (MFBDS)
- CVE-2018-12130: Microarchitectural Load Port Data Samling (MLPDS)
- CVE-2019-11091: Microarchitectural Data Sampling Uncacheable Memory
(MDSUM)
These updates contain the CPU Microcode adjustments for the software
mitigations.
to be installed with
zypper in -t patch openSUSE-2019-1806=1
here, running
lsb_release -rd
Description: openSUSE Leap 15.1
Release: 15.1
uname -rm
5.5.2-25.g994cf1f-default x86_64
rpm -qa | egrep "ucode-intel|firmware-intel"
ucode-intel-20191115-lp151.3.9.x86_64
kernel-firmware-intel-20200122-36.2.noarch
on an old, but otherwise functional, laptop,
cat /proc/cpuinfo | grep -i "model name"
model name : Intel(R) Core(TM) i3 CPU M 370 @ 2.40GHz
with mitigations enabled with,
cat /proc/cmdline
BOOT_IMAGE=/vmlinuz-5.5.2-25.g994cf1f-default ... mitigations=auto,nosmt ...
and
zypper in -t patch openSUSE-2019-1806=1
Loading repository data...
Reading installed packages...
'patch:openSUSE-2019-1806 = 1' is already installed.
Resolving package dependencies...
Nothing to do.
a check with
spectre-meltdown-checker.sh --version
Spectre and Meltdown mitigation detection tool v0.43
returns
...
CVE-2018-12126 aka 'Fallout, microarchitectural store buffer data sampling (MSBDS)'
* Mitigated according to the /sys interface: NO (Vulnerable: Clear CPU buffers attempted, no microcode; SMT disabled)
* Kernel supports using MD_CLEAR mitigation: YES (found md_clear implementation evidence in kernel image)
* Kernel mitigation is enabled and active: NO
* SMT is either mitigated or disabled: YES
> STATUS: VULNERABLE (Your kernel supports mitigation, but your CPU microcode also needs to be updated to mitigate the vulnerability)
CVE-2018-12130 aka 'ZombieLoad, microarchitectural fill buffer data sampling (MFBDS)'
* Mitigated according to the /sys interface: NO (Vulnerable: Clear CPU buffers attempted, no microcode; SMT disabled)
* Kernel supports using MD_CLEAR mitigation: YES (found md_clear implementation evidence in kernel image)
* Kernel mitigation is enabled and active: NO
* SMT is either mitigated or disabled: YES
> STATUS: VULNERABLE (Your kernel supports mitigation, but your CPU microcode also needs to be updated to mitigate the vulnerability)
CVE-2018-12127 aka 'RIDL, microarchitectural load port data sampling (MLPDS)'
* Mitigated according to the /sys interface: NO (Vulnerable: Clear CPU buffers attempted, no microcode; SMT disabled)
* Kernel supports using MD_CLEAR mitigation: YES (found md_clear implementation evidence in kernel image)
* Kernel mitigation is enabled and active: NO
* SMT is either mitigated or disabled: YES
> STATUS: VULNERABLE (Your kernel supports mitigation, but your CPU microcode also needs to be updated to mitigate the vulnerability)
CVE-2019-11091 aka 'RIDL, microarchitectural data sampling uncacheable memory (MDSUM)'
* Mitigated according to the /sys interface: NO (Vulnerable: Clear CPU buffers attempted, no microcode; SMT disabled)
* Kernel supports using MD_CLEAR mitigation: YES (found md_clear implementation evidence in kernel image)
* Kernel mitigation is enabled and active: NO
* SMT is either mitigated or disabled: YES
> STATUS: VULNERABLE (Your kernel supports mitigation, but your CPU microcode also needs to be updated to mitigate the vulnerability)
...
and
cat /sys/devices/system/cpu/vulnerabilities/mds
Vulnerable: Clear CPU buffers attempted, no microcode; SMT disabled
what additional mitigation, &/or specific microcode update is required to complete the mitigations?
--
To unsubscribe, e-mail: opensuse-security+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-security+owner(a)opensuse.org
