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

[sdack]

I for one dislike the messages of the standard kernel as it shows anyone booting up a system directly on the boot screen that it hasn't been compiled with the fixes. If the security flaws were of such an importance then it shouldn't be an option, and yet it is. I wonder if it isn't just the result of virtue signalling by some of the kernel devs. So now the message spams the boot screen where it only attracts unwanted attention, while not every single Linux machine on the planet needs to be 100% bullet proof.

[autonomous_cowherd]

Yeah, exactly, non-free software is okay as long as it cannot be replaced now?

That's been their approach for many years. If you can't change it then it's effectively hardware not software. I first came across it regarding an issue with one of the openmoko wireless interfaces, and it didn't make much sense to me then either.

[autonomous_cowherd]

Yeah, exactly, non-free software is okay as long as it cannot be replaced now?

There's no 'now' about it - that's been their view for many years. If you can't replace it then it's effectively part of the hardware, or so the argument goes. It wasn't new when it came up some years ago regarding one of the radio modules on the openmoko, and it didn't make much sense to me then either.

[dungeon]

Just tried, evertything works fine here:

DeVUAn:~$ cat /proc/sys/kernel/osrelease
4.16.0-gnu
DeVUAn:~$ cat /sys/devices/system/cpu/vulnerabilities/*
Not affected
Mitigation: __user pointer sanitization
Mitigation: Full AMD retpoline

I don't need firmware for mitigation, BTW even FGLRX works

DeVUAn:~$ fglrxinfo
display: :0.0 screen: 0
OpenGL vendor string: Advanced Micro Devices, Inc.
OpenGL renderer string: AMD Radeon HD 8400 / R3 Series
OpenGL version string: 4.5.13416 Compatibility Profile Context 15.302

On this AM1 machine, only firmares for AMD GPU are kind of *must have* (it also blocking newer AMD cpu microcode and realtek wired firmware, but things work fine enough without these)... but this way to be fair to not touch defaults in linux-libre at all, at least FGLRX blobby could fly in

GPUs are problem anywhere most of the time as expected

[WolfpackN64]

Then the warning should read "Linux-Libre is unsecure on this hardware due to CPU flaws. Do not use."

Just as regular Linux is unsecure on this or that hardware due to hardware/microcode flaws.

[admax88]

For more details:

https://security.googleblog.com/2018/01/more-details-about-mitigations-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.

[admax88]

Spectre/meltdown can be mitigated in software via KPTI and retpoline. This isn't as big a deal as you people are making it out to be.

[willmore]

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.

Then the warning should read "Linux-Libre is unsecure on this hardware due to CPU flaws. Do not use."

[WolfpackN64]

If anyone needs evidence that the FSF has gone full retard with its hardline 'free software or get lost' stance, this is the clearest of them all.

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.

[Sonadow]

If anyone needs evidence that the FSF has gone full retard with its hardline 'free software or get lost' stance, this is the clearest of them all.