Kicksecure: half the CPUs are shut off - expected behaviour?

Support
1

Setup:
Debian 10/11 + Kicksecure overlay

Hi everyone

After distromorphing, I noticed htop showed only 2 active cores, where beforehand were 4. This was the case with both Debian 10 and 11 + Kicksecure.

I confirmed with:

cat /sys/devices/system/cpu/offline
=> 1,3

cat /sys/devices/system/cpu/online
=> 0,2

cat /sys/devices/system/cpu/possible
=> 0-3

cat /sys/devices/system/cpu/present
=> 0-3

Documentation for these:

offline: cpus that are not online because they have been
HOTPLUGGED off or exceed the limit of cpus allowed by the
kernel configuration (kernel_max above).

online: cpus that are online and being scheduled.

possible: cpus that have been allocated resources and can be
brought online if they are present.

present: cpus that have been identified as being present in
the system

Though even if the cores are listed as possible and present, still only 2 of them are active at full workload.

The most likely culprit appears to be security-misc. Is this intentional?

If yes, what setting specifically causes this?
I haven’t found anything specifically mentioning this, and think it’s a good idea to document it, in case someone wants to be able to look into the implications and judge if the security/anonymity-gain is worth, what appears to be, half the CPU performance.

PS: Thank you for your groundbreaking work! And the Whonix-documentation is absolutely impressive and very insightful, the Whonix-Wikipedia article acknowledges that as well.

2

Thank you!

No, not explicitly expected as far as I know. Maybe @madaidan has an idea?

Check this documentation:
Disable CPU Mitigations

security-misc CPU hardening security settings have a performance penalty unfortunately but I didn’t benchmark how much. Other benchmark websites have run benchmarks for spectre etc.

Otherwise… Quite likely something in folder /etc/default/grub.d causing this. See:

for which files.

If you like to test… Disable (out comment) or delete. Run:

sudo update-grub

And reboot.

Otherwise similarly check folder /etc/sysctl.d.

Let me know how that goes.

3

Your help is greatly appreciated!

The cause was this line

## Force disable SMT as it has caused numerous CPU vulnerabilities.
##
##https://forums.whonix.org/t/should-all-kernel-patches-for-cpu-bugs-be-unconditionally-enabled-vs-performance-vs-applicability/7647/17
GRUB_CMDLINE_LINUX="$GRUB_CMDLINE_LINUX nosmt=force"

in

/etc/default/grub.d/40_cpu_mitigations.cfg

Commenting it out causes htop to recognize 4 cores again and the output of

cat /sys/devices/system/cpu/online

=> 0-3

and

cat /sys/devices/system/cpu/offline

being empty.

Now after looking into the issue, if I were running an intel processor I would reapply it, as deactivating SMT seems indeed important, even if the performance loss is significant.

The Whonix 15 changelog says:

SMT is disabled as it can be used to exploit the MDS vulnerability.

However the gain for AMD users seems not that much, especially considering the cost of, in this case, basically running a dual-core again.

Kernel-org on the topic of MDS-mitigation:

(I can’t link to it, probably because my account is too new)

MDS - Microarchitectural Data Sampling

Microarchitectural Data Sampling is a hardware vulnerability which allows unprivileged speculative access to data which is available in various CPU internal buffers.

Affected processors

This vulnerability affects a wide range of Intel processors. The vulnerability is not present on:

Processors from AMD, Centaur and other non Intel vendors

Older processor models, where the CPU family is < 6

Some Atoms (Bonnell, Saltwell, Goldmont, GoldmontPlus)

Intel processors which have the ARCH_CAP_MDS_NO bit set in the IA32_ARCH_CAPABILITIES MSR.

Running spectre-meltdown-checker prints for the SMT related entries:

STATUS: NOT VULNERABLE (your CPU vendor reported your CPU model as not vulnerable)

Now from that I conclude it seems reasonable for an AMD powered computer to not apply this quite costly setting.
Though am I missing any actual obvious mitigations or benefits for non-Intel processors?

I know that Whonix goals are to make sure to be on the safe side, and that makes perfect sense, the linked thread in the config-file also gave good reasons, yet it seems reasonable to think about only applying this setting to Intel-CPUs, in case others have similar performance losses, as the benefit seems actually not really there, but all the costs. Though feel free to disagree.

Edit:
I did some performance comparisons with the 7z benchmark which seems a good choice for real world data and it’s CPU focus:

7z b

The performance difference with that setting was indeed pretty close to 50%.

1 Like