Proposed Linux Patch Would Allow Disabling CPU Security Mitigations At Build-Time

[stormcrow]

I have the opposite opinion. In the longer term, it might be better to also hardcode the desired mitigations instead of having n! different combination to be dynamically selected and therefore the size of the kernel increases.

I tend to agree. From a security point of view, it's easier to just drop a config argument to the already signed kernel binary to turn mitigations off than it is to rebuild an entirely new kernel, sign it assuming SB is enabled and actually working (eff-u MSI), and reboot with no one the wiser on unattended hardware. No local console ever needed. The only way you block this is to make sure your boot loader has verifiably signed configuration files as well as the binary shim. Right now I think only the shim, kernel, and modules are signed but I could be wrong about that.

Basically you could end up with the same situation in other programs where a third party drops a bypass option in a config file which the original binary naively executes at runtime resulting in unintentional data revelation.

"Why would anyone bother if they already have root," you may ask? Persistence of malware presence. The less you have to do to alter the boot chain process, the easier it is to remain undetected. Most of the time malware scanners don't look at insecure defaults in config files, they're looking at binary hashes and other general behavior indicators. For example, almost no scanners will detect Python based malware.

[linuxgeex]

I propose for cpu manufacturers to produce cpus that don't need any mitigations...

They do. We just don't like what the performance looks like when they run in a truly safe mode, and that still doesn't fix platform side-channel attacks, so there still needs to be mitigations if you're exposed to attacks, ie you are on a network, even a firewalled one.

[linuxgeex]

To really have a migitations off option, it needs to be platform-wide. That is, the kernel and userspace. That means disabling mitigations compiled into userspace programs and libraries.

Sounds like a job for T2SDE!

But even that won't get rid of mitigations compiled into some JIT/Dynarec software, like Javascript engines, Java, QEMU.

Thankfully modern CPUs are becoming faster with mitigations enabled... in some cases faster than with mitigations disabled.

[erniv2]

Boot parameters are less work than building the kernel anew, I would say. However that way you could provide an "insecure" kernel as a package where you do not need to apply a patch but just set a config option (which would be guaranteed to work where a patch could need tweaking for each new kernel release).

I guess this flag is more for server fleets where you build one kernel and then patch them all, and not have to hack every bootconfig for every server/VM that runs on them it can get out of hand quickly 256 thread server host+255vms*8 racks now you have to edit 2048 config files well i guess you can automate that with some scripts but you need to write a script for that aswell so less maintenence time, just shove in the new kernel kexec and off you go if you want ~~.

[ll1025]

I propose for cpu manufacturers to produce cpus that don't need any mitigations...

I propose for software developers to just write secure code that doesn't need security patches.

[reba]

I propose for software developers to just write secure code that doesn't need security patches.

The code itself is secure. But undermined by insecure hardware.

[ll1025]

The code itself is secure. But undermined by insecure hardware.

Many of these bugs are only useful in combination with other vectors that leverage insecure code. Without those vectors, there's no code execution and thus no ability to exploit the hardware vulnerabilities.

It's hypocritical to point at the hardware vendors and say "just make secure hardware" (which involves unavoidable years-long dev cycles) when software devs with weeks-long dev cycles can't even get it right.