GNU Linux-Libre 4.16 Released, Won't Warn You About Spectre/Meltdown Microcode Updates

[lilos]

For more details:

https://security.googleblog.com/2018...for-cpu_4.html

Variant 1 can be mitigated by recompilation

Variant 2 can be mitigated by firmware updates _OR_ retpoline

Variant 3 can be mitigated via KPTI.

As a result linux-libre is fine.

And why linux-libre did not come with this fixes by default ?

How we can patch CVE-2017-5753 aka 'Spectre Variant 2'
with redpoline i don`t want to use intel microcode update!


################################################3

Checking for vulnerabilities on current system
Kernel is Linux 4.16.0-gnu #1 SMP Mon Apr 2 00:58:20 UTC 2018 x86_64
CPU is Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz

Hardware check
* Hardware support (CPU microcode) for mitigation techniques
* Indirect Branch Restricted Speculation (IBRS)
* SPEC_CTRL MSR is available: NO
* CPU indicates IBRS capability: NO
* Indirect Branch Prediction Barrier (IBPB)
* PRED_CMD MSR is available: NO
* CPU indicates IBPB capability: NO
* Single Thread Indirect Branch Predictors (STIBP)
* SPEC_CTRL MSR is available: NO
* CPU indicates STIBP capability: NO
* Enhanced IBRS (IBRS_ALL)
* CPU indicates ARCH_CAPABILITIES MSR availability: NO
* ARCH_CAPABILITIES MSR advertises IBRS_ALL capability: NO
* CPU explicitly indicates not being vulnerable to Meltdown (RDCL_NO): NO
* CPU microcode is known to cause stability problems: NO (model 23 stepping 10 ucode 0xa07)
* CPU vulnerability to the three speculative execution attack variants
* Vulnerable to Variant 1: YES
* Vulnerable to Variant 2: YES
* Vulnerable to Variant 3: YES

CVE-2017-5753 [bounds check bypass] aka 'Spectre Variant 1'
* Mitigated according to the /sys interface: YES (kernel confirms that the mitigation is active)
* Kernel has array_index_mask_nospec (x86): YES (1 occurence(s) found of 64 bits array_index_mask_nospec())
* Kernel has the Red Hat/Ubuntu patch: NO
* Kernel has mask_nospec64 (arm): NO
> STATUS: NOT VULNERABLE (Mitigation: __user pointer sanitization)

CVE-2017-5715 [branch target injection] aka 'Spectre Variant 2'
* Mitigated according to the /sys interface: NO (kernel confirms your system is vulnerable)
* Mitigation 1
* Kernel is compiled with IBRS/IBPB support: YES
* Currently enabled features
* IBRS enabled for Kernel space: UNKNOWN
* IBRS enabled for User space: UNKNOWN
* IBPB enabled: UNKNOWN
* Mitigation 2
* Kernel has branch predictor hardening (arm): NO
* Kernel compiled with retpoline option: YES
* Kernel compiled with a retpoline-aware compiler: NO (kernel reports minimal retpoline compilation)
> STATUS: VULNERABLE (Vulnerable: Minimal generic ASM retpoline)

CVE-2017-5754 [rogue data cache load] aka 'Meltdown' aka 'Variant 3'
* Mitigated according to the /sys interface: YES (kernel confirms that the mitigation is active)
* Kernel supports Page Table Isolation (PTI): YES (found 'CONFIG_PAGE_TABLE_ISOLATION=y')
* PTI enabled and active: YES
* Running as a Xen PV DomU: NO
> STATUS: NOT VULNERABLE (Mitigation: PTI)

[Delgarde]

Think they are doing disservice to their customers by not shipping blobs, if you have a choice between stock microcode that is known to be insecure and updated microcode that is known to implement mitigatio, choice should be fairly simple really. Purism is a nice ideal to strive for, but in the mean time choose lesser evil, please.

Out of curiosity, who do you think the customers (or lets say "users", since nobody is paying for it) are? Hint – they're the same kind of die-hard purists that would create a distro like this... they're not the kind of person who's going to be put off by a distro choosing ideology over practicality...

[unixfan2001]

The point here is that microcode is running anyway, inhibiting the update of what is loaded from UEFI or the ROM does not prove anything.

But it sure is easy.

Just delete code and brand yourself as "defender of FOSS" or something.

This is all bullshit I could do in 10 minutes myself by just deleting the firmware packages from my running system, and then rebooting.

How about they do something more useful than just deleting code?

Something that actually gives me hardware that respects my freedom instead of doing stupid cheap stunts that serve no purpose?

Is this all FSF has become? A PETA equivalent for free software?

I could actually see them "adopt" (as in, accept as donations) old hardware only to secretly smash it to bits behind people's backs.
Just as PETA will murder animals under their care. Supposedly, to prove a "point" (though what point exactly ... only they and their fellow psychopaths know or understand).

[starshipeleven]

No this is not all the FSF has become. Don't be daft.

"Well, we are waiting."

Don't leave me hanging like this.

[WolfpackN64]

The point here is that microcode is running anyway, inhibiting the update of what is loaded from UEFI or the ROM does not prove anything.

But it sure is easy.

Just delete code and brand yourself as "defender of FOSS" or something.

This is all bullshit I could do in 10 minutes myself by just deleting the firmware packages from my running system, and then rebooting.

How about they do something more useful than just deleting code?

Something that actually gives me hardware that respects my freedom instead of doing stupid cheap stunts that serve no purpose?

Is this all FSF has become? A PETA equivalent for free software?

No this is not all the FSF has become. Don't be daft.

[starshipeleven]

Think they are doing disservice to their customers by not shipping blobs, if you have a choice between stock microcode that is known to be insecure and updated microcode that is known to implement mitigatio, choice should be fairly simple really. Purism is a nice ideal to strive for, but in the mean time choose lesser evil, please.

As others said, microcode updates aren't required to mitigate this particular case, so in this specific case it's not an issue.

Overall, I agree with you, you cannot run without microcode and running with outdated microcodes does not make your system more less free or freedom-respecting. It's like painting the fence yellow and then claiming that the yellow fence makes your PC respect your freedom more. Does not change anything.

[starshipeleven]

The FSF has always promoted extreme solutions because someone needs to show people just how much proprietary code runs on their systems. It's not a pragmatic approach, but no one expects it to be.

The point here is that microcode is running anyway, inhibiting the update of what is loaded from UEFI or the ROM does not prove anything.

But it sure is easy.

Just delete code and brand yourself as "defender of FOSS" or something.

This is all bullshit I could do in 10 minutes myself by just deleting the firmware packages from my running system, and then rebooting.

How about they do something more useful than just deleting code?

Something that actually gives me hardware that respects my freedom instead of doing stupid cheap stunts that serve no purpose?

Is this all FSF has become? A PETA equivalent for free software?

[waxhead]

Think they are doing disservice to their customers by not shipping blobs, if you have a choice between stock microcode that is known to be insecure and updated microcode that is known to implement mitigatio, choice should be fairly simple really. Purism is a nice ideal to strive for, but in the mean time choose lesser evil, please.

Give the FSF a break. Some of them might be fanatic , but then again many of us here are fanatic about Linux, some filesystem, some programs. some harddisk brands etc etc...
There are far worse things in the world happening because of fanatics who even cut peoples head off, so for some to try to push for an ideal world where knowledge is shared (yes, programs are knowledge) is not really that bad is it?

Just imagine if Wikipedia suddenly closed for example? Let's be glad that someone tries to share knowledge for free. And besides, FSF made their goal right? Now people are talking about they not warning against vulnerable hardware which in itself is just one more reason to open up the code.

I will admit that they could have put up a warning. "hey, your hardware sucks, and because someone is not as idealistic as we are, we can't fix it either", that would have made more sense, but at least they get people talking until we are all on RISC-V hardware

[R41N3R]

So rather than suggesting to update the non-free FW to something more secure, it would rather you stick with the old, less secure non-free FW that comes on the chip because suggesting a non-free firmware update would violate your freedom?

The logic seems incoherent to me.

EDIT: Better solution, rather than remove it, change the warning to something noting the HW is vulnerable.

Yes, it would have been better to warn the user that the non-free firmware of the specific hardware is vulnerable.

[iugamarian]

Actually doing a firmware update on a Core I5-6400 disables (protect CPU from) the ability to overclock it by BCLK on Z170 board that has an older BIOs to allow it. And as admax88 and dungeon show you can be secure without firmware updates. So I actually really badly don't need firmware updates. BCLK overclock gives a stable 150% increase in CPU performance, can go up to 180% but it's then too stressed.