GCC 7.3 Preparing For Release To Ship Spectre Patches

[Emmanuel Deloget]

Done Full AMD reptoline mitigation. I forgot to add spectre_v2=on to grub.
But now I'm thinking of turning it off it goes against my principles. I'm a pro-liberty guy. Let's not forget this famous Benjamin Franklin Quotation.

I'm failing to see how protecting your computer from a nasty security disaster has any kind of effect on your liberty but, hey, you're free to think otherwise

[oibaf]

I'm failing to see how protecting your computer from a nasty security disaster has any kind of effect on your liberty but, hey, you're free to think otherwise

There is the issue that Spectre v2 mitigation requires updated non-free CPU microcode.
However retpoline mitigation doesn't require updated microcode, so this is a better option, not only for performance but also for liberty.

[Kayote]

Also there is the issue that we don't know if this actually fixes the vulnerabilites at all as there unknown exploits on AMD platforms. This could provide little security on no security at all. I think from AMD side they need to provide better clear information. IMHO . I think turning off AMD complete mitigation as Torvalds did it's a sane decision, it's telling AMD keep your word or shut up, otherwise.

[Kayote]

I really like what Torvalds is doing he left everything set up to roll out full AMD mitigation, but he turned off by default on grub. LOL he is just playing with them, he must just turn it off/on again by default in git version or releases candidates. And it's clearly the pro-liberty choice some distros might turn on full AMD mitigation, some not. Every distro can have there own criteria.

[Kayote]

oibaf thanks for the info, I guess you can actually run less obscure outdated cpu microde? running kernel firmware from may 2017 I and I'm still getting Minimal AMD ASM retpoline. Too bad I had to search all over web archives, wayback machine, etc. Opensuse likes too delete older firmwares.

[Emmanuel Deloget]

There is the issue that Spectre v2 mitigation requires updated non-free CPU microcode.
However retpoline mitigation doesn't require updated microcode, so this is a better option, not only for performance but also for liberty.

Thou shall be kiding

Your CPU already has micro-code. Hell, it's a CISC CPU and they always contain microcode (although the fact that it's reachable and writable is quite "recent"). It's part of how they are architectured

[etfe]

The original article says "there has been talk that [Retpoline support] will be back-ported all the way to GCC 4.x compilers". Does anyone know where I could find such talk, with the goal of following it and guessing when we might see such a backport? We have some CentOS 7 systems, which are still on gcc 4.x, so it seems this backport would be needed to get a fully Retpoline-enabled kernel for these systems.