retpoline+IBPB is NOT? needed to mitigate the vulnerability on some CPUs

[kuzetsa]

BTI (CVE-2017-5715) mitigation: retpoline alone, without IBPB might be acceptable
... at least on some CPUs

in particular:$ cat /sys/devices/system/cpu/vulnerabilities/spectre_v2

Mitigation: Full generic retpoline

... for some CPUs, acceptable mitigation (with minimal overhead penalties) can be had from an updated compiler, kernel, and system-wide userland rebuild to enable retpoline.
(and/or update all premade binary packages, as appropriate)

IBPB is painfully slow, and in cases where intel's testing hasn't shown it to be required, IBPB is a senseless penalty for little (if any) gains compared to a retpoline-only BTI mitigation.

---

This is a secondary source (not directly from intel):

https://github.com/marcan/speculation-bugs/blob/master/README.md#cpu-vendor-response

[ Alternatively, Intel is recommending retpolines for BTI, especially on current processors where that may be faster than the microcode patches for IBPB. Retpolines also require a microcode patch on Broadwell and newer CPUs ]

---

I tried tracking down the specific quote where intel made the recommendation to use retpoline without IBPB for performance reasons, but gave up after 30 minutes of digging.

Update:

Sorry. I didn't explicitly say which version of retpoline:

I was only thinking about upstream / kernel.org support (for example, on 4.15.x series kernels) and completely forgot that several distros have a patchset for older kernel branches. That flavor of retpoline-type mitigation is primarily developed by the distro's kernel maintainer(s).

[Potato-Matic]

I'd be really interested to know whether this is the case. I've got a lot of machines that are frustraightingly just outside the window of what Intel has decided they want to provide microcode updates for. (a LOT of institutions haven't bought all new computers in the last five years)

I'm no kernel dev, but I wonder if anyone's looked at an equivalent of IBPB for older machines that Intel has recently decided never touch. If an attacker can stuff the branch predition buffer by repeatedly jumping, why can't we? I understand it'd be slow as all hell, but might provide a fallback for those left in the lurch.

[orachas]

Oracle has a useful blog post on this subject:
https://blogs.oracle.com/linux/an-update-on-retpoline-enabled-kernels-for-oracle-linux-v2

The author links to this Intel document:
https://software.intel.com/sites/default/files/managed/1d/46/Retpoline-A-Branch-Target-Injection-Mitigation.pdf

In this document, I see the following commentary:

"5.1 Processor Models - Retpoline is known to be an effective branch target injection (Spectre variant 2) mitigation on Intel processors belonging to family 6 (enumerated by the CPUID instruction) that do not have support for enhanced IBRS. On processors that support enhanced IBRS, it should be used for mitigation instead of, or in combination with, retpoline."

"Retpoline is a hybrid approach since it requires updated microcode to make the speculation hardware behavior more predictable on some processor models."

I also understand that some peripheral devices include (x86) firmware that may be executed by the kernel which might use branching that is vulnerable to speculative attack. I am assuming that overrides the following document text:

"Kernels which were built with a compiler that does support retpoline will indicate that
they are mitigated and are no longer vulnerable: ... Mitigation: Full generic retpoline"

[Potato-Matic]

Yeah, I vaugely recall reading that some of the microcode-supplied features were being used to protect against speculation inside of calls to firmware. (when it comes to spectre/meltdown, good luck getting support/patches for that stuff)

Speaking of CPUs that won't receive IBRS or IBPB microcode updates and may not need them, I have an AMD Phenom-based machine which is reported to have "Full AMD Retpoline" yet is still "vulnerable" because it lacks IBPB. Does AMD plan to release/has released microcode updates to introduce these features?

EDIT: I'm a dumb*** for not googling it. AMD has released IBPB microcode for at least some processors. Installing 'amd64-microcode' (this is a fresh install to get the new kernel patches) doesn't seem to change which version of the microcode I've got, though It's possible it hasn't trickled down to me yet.

I'd be interested if anyone's looked at a slow software IBRS or IBPB, but all signs I've seen point to it being a microcode-only thing.

[kuzetsa]

I'd be interested if anyone's looked at a slow software IBRS or IBPB, but all signs I've seen point to it being a microcode-only thing.

I wasn't able to mentally parse that sentence, @Matthew-Bradley

I've tested the intel microcode update which is available for one of my systems which is NOT on the list of CPUs: "this one absolutely requires IBPB because retpoline-only is ineffective" and the performance hit (increased latency) was measurable.

If I get the time I'll shuffle around and cook the data into a human-readable report which isn't nearly as opaque as the raw data.

---

(edit) Also, as @orachas mentioned - yeah binary blob firmware is hard to trust, and I'm uncertain to what extent BTI (spectre v2) is able to peer outside its process to look inside the memory space of things which were built using a retpoline-type compiler. ::ponder::

[orachas]

To be specific, the 0.35 version of the script tested this file:

# cat /sys/devices/system/cpu/vulnerabilities/spectre_v2
Mitigation: Full AMD retpoline

In 0.35, if the word "Full" was found here, then the script reported "Not Vulnerable" with the following test:

elif grep -qw Full /sys/devices/system/cpu/vulnerabilities/spectre_v2; then
retpoline_compiler=1
pstatus green YES "kernel reports full retpoline compilation"

This reporting was changed on April 4th with a commit titled "feat: rework Spectre V2 mitigations detection w/ latest vanilla & Red Hat 7 kernels" where the script began demanding IBPB. I don't see any commentary on why this was done. I would like to know more detail on the reasons for this change, and who was involved.

On another subject, the Oracle blog post in my last comment also mentions 3rd-party kernel modules. These must also be prepared with a retpoline-aware compiler - otherwise they can be successfully targeted in a speculative attack, and a dmesg fragment is provided that specifically warns of this condition. Non-retpoline modules join device x86-firmware that the kernel executes as vectors to reintroduce the vulnerability.

I am not convinced that "Full AMD retpoline" is now once again completely vulnerable, and it appears to me that all the code in my distro's kernel package is safe. I would like to know how to identify unsafe peripherals, activities, and what countermeasures are possible when IBPB is not available.

[Potato-Matic]

To rephrase: As far as I know, nobody has looked at an alternative (even a horifyingly slow one) to the requirement that you have IBPB in microcode to go along with retpoline (both for Intel and AMD). I would have thought it would be possible but nothing specifically points to it. (if an attacker can do repeated jumps to poison the buffer, then instead of clearing it on context-switch with IBPB I would have thought we could do the same jumping around to un-poison it)

To the best of my understanding, being a non-expert in this stuff:
IBPB is needed because an attacking program can do a bunch of jumping within it's own memory space, which then results in speculation in another process that runs some "gadget" piece of code that wouldn't normally run (and leaks data). Recompiling the Kernel with retpoline protects gadgets from being found in the kernel. Recompiling web browsers prevents gadgets being found in web browsers. HOWEVER, because a lot of software out there isn't compiled with retpoiline, an attacker could still do a bunch of jumping and trigger a gadget in some other program that doesn't have retpoline. It could also do it before a call to some firmware, which almost certainly won't have retpoline and could be full of "gadgets" that will leak data. By having IBPB, you can clear the poisoned buffer before entering software that doesn't have retpoline, including firmware.

All of this comes with the asterisk though that this is just what I've been able to understand from what I've read on the subject. If a kernel developer who wrote the protections wants to chime in, I'd be really grateful.

EDIT: I imagine kernel modules probably need retpoline too, not just the kernel itself.

[kuzetsa]

@orachas - Ah! Good catch. de02dad is a major rewrite, and this may just be a regression / mistake (unintended consequence from the logic changes).

---

Edit:

@Matthew-Bradley yes. I mentioned the recompilation (and/or update all premade binary packages, as appropriate) in the original post.

I feel It's worth noting: retpoline was an early fix, and predates the development of IBPB-type microcode, which was then discussed on LKML (among other places) and various people weighed in using strong language (some calling it garbage, or worse)

As I understand, one of the reasons IBPB microcode was released is because of legacy software (which wouldn't be recompiled in a timely manner) running in enterprise situations where shutting down production servers would disrupt mission critical infrastructure.

[Potato-Matic]

For reference, some of the best descriptions I've found:
https://lkml.org/lkml/2018/1/4/622
and specifically regarding KVM:
https://lkml.org/lkml/2018/2/1/638

EDIT: Overall this doesn't look like a mistake to me, and I'd want confirmation from someone who's really familiar with how IBPB is being used before deciding that some oder CPUs are safe.

[kuzetsa]

@Matthew-Bradley yeah, that stuff looks right to me. Those details are correct.

1. [PATCH 1/7] x86/feature: Detect the x86 feature to control Speculation (early january) predates the wide availability and deployment of mature retpoline-type compilers. Note the lack of any mention for retpoline-type fixes.
   ... (smol edit: oops I mispasted the thread name originally)

2. [PATCH v6 2/5] KVM: x86: Add IBPB support (Feb 1st) mentions a case of a CPU where IBPB is required (skylake in particular, is known to be an example), but also specifically mentions a usage case where retpoline is an alternative mitigation strategy which doesn't involve IBPB, but again mentioning the skylake exception.

I was careful when I file this issue to use qualifying language: "on some CPUs", as skylake is on the list which is known to require IBPB.

---

Addendum: One of the things mentioned in the february LKML thread (KVM-related patch) is guests being attacked by a different guest on the same host:

https://news.ycombinator.com/item?id=16127800

It's been discussed by various people that guests can protect themselves with retpoline-compiled userland code & guest kernel in the absence of IBPB. (assuming not a skylake or other affected CPU which needs IBPB). I guess that makes sense to me.

[speed47]

Thanks for all your research.

I added IBPB as a requisite to "NOT VULNERABLE" on variant 2 after seeing how Red Hat changed the default protection in their latest kernels.
You can see here https://access.redhat.com/articles/3311301#indirect-branch-prediction-barriers-ibpb-10 that they automatically enable IBPB when the user enables Retpoline. This is also the default.

In the vanilla kernel, IBPB is now also enabled in any case when it's available, including when the kernel has been compiled with retpoline (vanilla kernel actually doesn't support IBRS appart from the specific IBRS_FW for the firmware code):
https://elixir.bootlin.com/linux/v4.16.2/source/arch/x86/kernel/cpu/bugs.c#L286

So it would seem that the code implies that IBPB is not useless with retpoline, quite the contrary.

However it does mean that a lot of CPUs that don't yet (or never will) have a microcode update will get VULNERABLE with no way to fix it. To avoid freaking out people, I could create a --paranoid to check for IBPB Spectre 2 and ignore it otherwise...

I'd like to get this sorted before releasing v0.37.

[Potato-Matic]

@kuzetsa Are you sure you're not confusing IBRS and IBPB? My understanding is that skylake needs IBRS, because it will occasionally fall back to the poisoned buffer on returns, so retpoline is insufficient by itself. Aparently "retpoline underflow" now fixes this and IBRS is no longer necessarily needed on skylake. IBPB is still needed everywhere to protect against exploitation of software/firmware/ect that has not been compiled with retpoline. In the case of firmware, it's entierly possible it never will be.

EDIT: upon reading the code linked above, it seems IBRS is also used when dealing with firmware and such.

[orachas]

How about the following warning:

Retpoline WITHOUT IBPB - modules, firmware, and BIOS/ACPI/UEFI may introduce vulnerable code

I read a quick discussion of [when] the OS executes various types of BIOS code here:

https://superuser.com/questions/462314/what-are-the-functions-of-the-bios-while-the-operating-system-is-running

[kuzetsa]

@Matthew-Bradley You linked https://lkml.org/lkml/2018/2/1/638 and it mentions IBPB (no mention of IBRS) - I'm a bit confused by your question, honestly.

@speed47 - yeah, IBPB covers things which won't otherwise be able to protect themselves using cheaper (less overhead) retpoline-based compilation.

Like - maybe as an alternative to the more generic: "vulnerable" message, when "full retpoline" is detected in the kernel but IBPB is NOT detected, a brief notice that sensitive userspace processes need retpoline mitgations:

"unless IBPB is enabled, older binaries built without a retpoline-type compiler are vulnerable to BTI (CVE-2017-5715) attacks"
... or something like that.

@orachas - yeah, binary blob firmware which can't be audited for security is never trustworthy IMO :(

[Potato-Matic]

That link was mostly in reference to IBPB
There's more info (including IBRS) here as well: #111
Particularly in the excerpt from the kml.

Reading over the code @speed47 linked, it seems IBRS is also used to protect firmware (X86_FEATURE_USE_IBRS_FW). I don't know what's going on with AMD in that case though, since I've only heard about IBPB from them.
/* * Retpoline means the kernel is safe because it has no indirect * branches. But firmware isn't, so use IBRS to protect that. */

[speed47]

AMD plans to implement IBRS for at least some CPUs, at they have published information about how to detect an IBRS-capable AMD processor (a different CPUID bit than Intel). This CPUID bit is already checked by the script, but I haven't seen any AMD CPU with it yet.

[kuzetsa]

@Matthew-Bradley I think IBRS is only available on newer intel CPUs, so I believe anything older than ... skylake? won't have IBRS.
(I don't recall IBRS being part of the microcode updates for 1.3ghz sandybridge-based "dualcore i3 potato" in my ultrabook)

IBRS in particular has performance hits which torvalds described as a "vile hack", and my own hot take on the intel microcode this agrees with that kind of criticism:

Compared to compiler-level changes, one-size-fits-all microcode "fixes" are a blunt instrument which breaks optimizations for the sake of security. (and I have some firsthand test data on IBPB. it's quite bad for my usual workloads. haven't got relevant hardware to test IBRS though)

It's possible that a future version of microcode-type spectre mitigation(s) will be computationally LESS expensive (and able to be managed with a fine-grained approach by the kernel) compared to compiler-level (still optimized) retpoline.

Seems more likely that a speedup-type microcode will be possible if it's selectively managed by the "IL to assembly" stage in optimizing compilers (or whichever other level that would need to happen at).

I think "the good stuff" isn't coming to my sandybridge potato though. My only choices are retpoline or major peformance hits.
"Maybe some day" [tm]

Edit: Oh!!! intel CPUs older than skylake do have IBRS support, but at or around the skylake models (42nd generation i7 or whatever) is when the relevant hardware "under the hood" to make it less expensive existed.

Older CPUs have a worse performance hit with the microcode updates. (oops)

---

^ getting a bit offtopic.

thanks for looking at the nuance & considering a rework the IBPB-related notice(s), @speed47

[orachas]

Intel originally said that they would only produce new microcode for CPUs manufactured within the last 5 years.

They have since widened that net, and some older CPUs will get firmware when convenient, so IBPB might appear on older systems.

https://it.slashdot.org/story/18/04/04/1333252/intel-says-some-cpu-models-will-never-receive-microcode-updates

I have Core 2 Duos and Athlons that will never get it.

[Potato-Matic]

@orachas The article you've linked would seem to support the opposite: That intel origionally intended to provide microcode updates furthur back, but have now issued a "stop" for anything older than five years.

https://rcpmag.com/blogs/scott-bekker/2018/03/intel-meltdown-spectre-updates-done.aspx
and more recently (april 4th):
https://hexus.net/tech/news/cpu/116885-intel-halts-microcode-patch-development-230-cpus/
says that intel has stopped working on microcode updates. Do you have a link to a more up-to-date release that says otherwise?

[orachas]

I just googled "microcode stopped" and found your hit:

http://www.hexus.net/tech/news/cpu/116885-intel-halts-microcode-patch-development-230-cpus/

"We've now completed release of microcode updates for Intel microprocessor products launched in the last 9+ years that required protection against the side-channel vulnerabilities discovered by Google Project Zero."

[Potato-Matic]

Ah, yes. I missed that bit added to the bottom from a separate source. Not sure how much I trust it though.

Googling around, a bunch of places have the more complete quote:
"We've now completed release of microcode updates for Intel microprocessor products launched in the last 9+ years that required protection against the side-channel vulnerabilities discovered by Google Project Zero," Intel said in a statement sent to us. "However, as indicated in our latest microcode revision guidance, we will not be providing updated microcode for a select number of older platforms for several reasons, including limited ecosystem support and customer feedback."

It seems to me there won't be many more patches for older stuff though, either way.

[speed47]

Just pushed the ibpb branch with the following change:

IBPB is not required to get "not vulnerable" for Variant 2, however a warning will be shown below the status. If --paranoid is specified IBPB is required for retpoline or IBRS to be considered as a complete Variant 2 mitigation.

[kuzetsa]

the spirit of #181 - ["... IBPB is NOT? needed..."]:

I feel that the microcode "fix" (rather, its current blunt instrument incarnation) from intel is contentious, and it nearly comes across as disingenuous (err, dubious? some better word probably.) for the message to still be present (and red) when --paranoid is disabled:

[speaking for myself / my views]
the new warning message (current wording as-of: 223f502) sends a mixed message by showing the nag when --paranoid is disabled. As for the wording, I think ...

${OpinionOmmited}

... 0919f5c contains several (debatable?) assertions which, I suspect, are likely the views of a particular distro, security team, or person, rather than the fruits of a democratic consensus. It's a big commit, and full of a lot of words, and I would've used different words if I wrote the explanation? Either way is fine.

Semi-unrelatedly, the wording for --disclaimer is great:

Please also note that for Spectre vulnerabilities, all 
software can possibly be exploited, this tool only 
verifies that the kernel (which is the core of the system) 
you're using has the proper protections in place. 
Verifying all the other software is out of the scope of 
this tool. As a general measure, ensure you always have 
the most up to date stable versions of all the software 
you use, especially for those who are exposed to the 
world, such as network daemons and browsers.

[Potato-Matic]

@kuzetsa All of the microcode patches are quite a bit more mature by this point, with Intel no longer choosing to patch any more chips. While early patches were plauged with issues, they're now probably as finalized as they're going to be considering how difficult microcode patches can be. They're also important enough to coverage that AMD released an update this week (4/10/18): https://www.amd.com/en/corporate/security-updates

As @speed47 noted, IBPB is getting enabled in the vanilla kernel even with retpoline in place. If it's getting used by the kernel for protection then I definitely think that it's something to allways warn about when it's not there. That's why I agree with @speed47 's above reasoning to allways include a warning, but only change the toplevel status when "paranoid". I think that's a good compromise, similar to informing when the performance impact of PTI will be not be reduced.

While I'd like to see the availability of IBRS and IBPB geting noted because of all their various uses (like mitigating firmware speculation or with KVM) those are things that may or may not fall under "core of the system" protection.

[Potato-Matic]

One other thing to look into is an article I just found going through the various AMD mitigation strategies:
https://www.techarp.com/guides/amd-spectre-mitigation-guide/

What might be relavent to this this thread is that it's stated that AMD has mitigations you can implement that are software+hardware OR software only, though I've not seen any speak of software only naywhere else, and the link to their release in my previous comment would seem to contradict that, considering they speak exclusively of a combined approach. The witepaper they give is probably worth a look.

[kuzetsa]

All of the microcode patches are quite a bit more mature by this point, with Intel no longer choosing to patch any more chips. [...]

@Matthew-Bradley nah, that's not true - they only discontinued further microcode development for very old CPUs. Lots of the modern CPUs are still getting microcode updates.

[orachas]

One thing that I want to point out in closing - the Red Hat retpoline implementation is not extensive or thorough. It will not report "Full generic retpoline" or "Full AMD retpoline" on any CPU (it will report "Full retpoline" when new microcode is available). I hope the scanner script refrains from putting too much faith in what I see to be code of questionable quality. The (very brief) port was entirely performed by Josh Poimboeuf:

# rpm -q --changelog kernel | egrep -i '(spectre|retpo)'
- [x86] retpoline: Optimize inline assembler for vmexit_fill_RSB (Josh Poimboeuf) [1539649 1535644]
- [x86] spectre/meltdown: avoid the vulnerability directory to weaken kernel security (Josh Poimboeuf) [1539649 1535644]
- [x86] spec_ctrl: Document retpolines and ibrs_enabled=3 (Josh Poimboeuf) [1539649 1535644]
- [x86] spec_ctrl: upgrade GCC retpoline warning to an error (Josh Poimboeuf) [1539649 1535644]
- [x86] spec_ctrl: enforce sane combinations of IBRS and retpoline (Josh Poimboeuf) [1539649 1535644]
- [x86] spec_ctrl: detect unretpolined modules (Josh Poimboeuf) [1539649 1535644]
- [x86] retpoline: Add LFENCE to the retpoline/RSB filling RSB macros (Josh Poimboeuf) [1539649 1535644]
- [x86] retpoline: Fill return stack buffer on vmexit (Josh Poimboeuf) [1539649 1535644]
- [x86] retpoline/xen: Convert Xen hypercall indirect jumps (Josh Poimboeuf) [1539649 1535644]
- [x86] retpoline/hyperv: Convert assembler indirect jumps (Josh Poimboeuf) [1539649 1535644]
- [x86] retpoline/ftrace: Convert ftrace assembler indirect jumps (Josh Poimboeuf) [1539649 1535644]
- [x86] retpoline/entry: Convert entry assembler indirect jumps (Josh Poimboeuf) [1539649 1535644]
- [x86] retpoline/crypto: Convert crypto assembler indirect jumps (Josh Poimboeuf) [1539649 1535644]
- [x86] retpoline: Add initial retpoline support (Josh Poimboeuf) [1539649 1535644]
- [tools] objtool: Detect jumps to retpoline thunks (Josh Poimboeuf) [1539649 1535644]
- [x86] spectre: Add boot time option to select Spectre v2 mitigation (Josh Poimboeuf) [1539649 1535644]
- Revert "x86/entry: Use retpoline for syscall's indirect calls" (Andrea Arcangeli) [1519795 1519798]
- [x86] entry: Use retpoline for syscall's indirect calls (Josh Poimboeuf) [1519795 1519798] {CVE-2017-5715}

Oracle's current implementation in their UEKr4 appears to be a much more extensive effort, involving more people. It does report the "Full" status where Red Hat will not, and it certainly appears from this changelog to be far more robust:

# rpm -q --changelog kernel-uek | egrep -i '(spectre|retpo)'
- x86/spectre_v2: Fix cpu offlining with IPBP. (Konrad Rzeszutek Wilk)
- retpoline: selectively disable IBRS in disable_ibrs_and_friends() (Chuck Anderson) [Orabug: 27636063]
- retpoline: move setting of sysctl_ibrs_enabled and sysctl_ibpb_enabled to where SPEC_CTRL_IBRS_INUSE and SPEC_CTRL_IBPB_INUSE are set (Chuck Anderson) [Orabug: 27556096]
- retpoline: set IBRS and IBPB in use only on the boot CPU call to init_scattered_cpuid_features() (Chuck Anderson) [Orabug: 27556096]
- retpoline: display IBPB feature status along with IBRS status (Chuck Anderson) [Orabug: 27556096]
- retpoline: move lock/unlock of spec_ctrl_mutex to check_modinfo() (Chuck Anderson) [Orabug: 27556096]
- retpoline: call clear_retpoline_fallback() with boot parm spectre_v2_heuristics=off (Chuck Anderson) [Orabug: 27556096]
- retpoline: add brackets to check_ibrs_inuse() and clear_ibpb_inuse() (Chuck Anderson) [Orabug: 27556096]
- retpoline/module: do not enable IBRS/IPBP if SPEC_CTRL_IBRS_ADMIN_DISABLED/SPEC_CTRL_IBPB_ADMIN_DISABLED is set (Chuck Anderson) [Orabug: 27547729]
- retpoline: microcode incorrectly reported as broken during early boot (Chuck Anderson) [Orabug: 27556096]
- retpoline: move lock/unlock of spec_ctrl_mutex into init_scattered_cpuid_features() (Chuck Anderson) [Orabug: 27556096]
- Revert "x86/spec_ctrl: Add 'nolfence' knob to disable fallback for spectre_v2 mitigation" (Konrad Rzeszutek Wilk) [Orabug: 27601790]
- x86/spectre_v2: Fix the documentation to say the right thing. (Konrad Rzeszutek Wilk)
- x86/spectre_v2: Don't check bad microcode versions when running under hypervisors. (Konrad Rzeszutek Wilk) [Orabug: 27601735]
- x86/spectre: move microcode check before kernel ibrs flags are set (Daniel Jordan) [Orabug: 27534557] {CVE-2017-5715}
- retpoline/module: fall back to another spectre mitigation when disabling retpoline (Chuck Anderson) [Orabug: 27457402]
- retpoline/module: add bit defs for use_ibpb (Chuck Anderson) [Orabug: 27457402]
- x86/spectre_v2: Only use IBRS when ibrs_inuse tells us to (Konrad Rzeszutek Wilk)
- x86/spectre_v2: Disable IBRS if spectre_v2=off (Konrad Rzeszutek Wilk)
- x86/spectre_v2: Remove 0xc2 from spectre_bad_microcodes (Darren Kenny) [Orabug: 27523395]
- x86/spectre_v2: Add spectre_v2_heuristics= (Konrad Rzeszutek Wilk) [Orabug: 27478139] {CVE-2017-5715}
- x86/spectre_v2: Do not disable IBPB when disabling IBRS (Konrad Rzeszutek Wilk) [Orabug: 27478139] {CVE-2017-5715}
- x86/spectre: Favor IBRS on Skylake over retpoline (Konrad Rzeszutek Wilk) [Orabug: 27478139] {CVE-2017-5715}
- x86/spectre: Now that we expose 'stbibp' make sure it is correct. (Konrad Rzeszutek Wilk) [Orabug: 27478139] {CVE-2017-5715}
- x86/cpufeatures: Clean up Spectre v2 related CPUID flags (David Woodhouse) [Orabug: 27478139] {CVE-2017-5715}
- x86/spectre_v2: Don't spam the console with these: (Konrad Rzeszutek Wilk) [Orabug: 27478139] {CVE-2017-5715}
- x86/cpufeature: Blacklist SPEC_CTRL/PRED_CMD on early Spectre v2 microcodes (David Woodhouse) [Orabug: 27478139] {CVE-2017-5715}
- x86/spectre_v2: Print what options are available. (Konrad Rzeszutek Wilk) [Orabug: 27478139] {CVE-2017-5715}
- x86/spectre_v2: Add VMEXIT_FILL_RSB instead of RETPOLINE (Konrad Rzeszutek Wilk) [Orabug: 27478139] {CVE-2017-5715}
- x86/spectre: If IBRS is enabled disable "Filling RSB on context switch" (Konrad Rzeszutek Wilk) [Orabug: 27478139] {CVE-2017-5715}
- x86/spectre_v2: Don't allow {ibrs,ipbp,lfence}_enabled to be toggled if retpoline (Konrad Rzeszutek Wilk) [Orabug: 27478139] {CVE-2017-5715}
- x86/spectre: Fix retpoline_enabled (Konrad Rzeszutek Wilk) [Orabug: 27478139] {CVE-2017-5715}
- x86/spectre: Update sysctl values if toggled only by set_{ibrs,ibpb}_disabled (Konrad Rzeszutek Wilk) [Orabug: 27478139] {CVE-2017-5715}
- retpoline/module: Taint kernel for missing retpoline in module (Andi Kleen) [Orabug: 27478139] {CVE-2017-5715}
- x86/retpoline: Fill RSB on context switch for affected CPUs (David Woodhouse) [Orabug: 27478139] {CVE-2017-5715}
- x86/retpoline: Optimize inline assembler for vmexit_fill_RSB (Andi Kleen) [Orabug: 27478139] {CVE-2017-5715}
- retpoline: Introduce start/end markers of indirect thunk (Masami Hiramatsu) [Orabug: 27478139] {CVE-2017-5715}
- x86/retpoline: Add LFENCE to the retpoline/RSB filling RSB macros (Tom Lendacky) [Orabug: 27478139] {CVE-2017-5715}
- x86/retpoline: Remove compile time warning (Thomas Gleixner) [Orabug: 27478139] {CVE-2017-5715}
- x86/retpoline: Fill return stack buffer on vmexit (David Woodhouse) [Orabug: 27478139] {CVE-2017-5715}
- x86/retpoline/irq32: Convert assembler indirect jumps (Andi Kleen) [Orabug: 27478139] {CVE-2017-5715}
- x86/retpoline/checksum32: Convert assembler indirect jumps (David Woodhouse) [Orabug: 27478139] {CVE-2017-5715}
- x86/retpoline/xen: Convert Xen hypercall indirect jumps (David Woodhouse) [Orabug: 27478139] {CVE-2017-5715}
- x86/retpoline/hyperv: Convert assembler indirect jumps (David Woodhouse) [Orabug: 27478139] {CVE-2017-5715}
- x86/retpoline/ftrace: Convert ftrace assembler indirect jumps (David Woodhouse) [Orabug: 27478139] {CVE-2017-5715}
- x86/retpoline/entry: Convert entry assembler indirect jumps (David Woodhouse) [Orabug: 27478139] {CVE-2017-5715}
- x86/retpoline/crypto: Convert crypto assembler indirect jumps (David Woodhouse) [Orabug: 27478139] {CVE-2017-5715}
- x86/spectre_v2: Add disable_ibrs_and_friends (Konrad Rzeszutek Wilk) [Orabug: 27478139] {CVE-2017-5715}
- x86/spectre_v2: Figure out if STUFF_RSB macro needs to be used. (Konrad Rzeszutek Wilk) [Orabug: 27478139] {CVE-2017-5715}
- x86/spectre_v2: Figure out when to use IBRS. (Konrad Rzeszutek Wilk) [Orabug: 27478139] {CVE-2017-5715}
- x86/spectre: Add IBRS option. (Konrad Rzeszutek Wilk) [Orabug: 27478139] {CVE-2017-5715}
- x86/spectre: Add boot time option to select Spectre v2 mitigation (David Woodhouse) [Orabug: 27478139] {CVE-2017-5715}
- x86/retpoline: Add initial retpoline support (David Woodhouse) [Orabug: 27478139] {CVE-2017-5715}
- x86/spec: Fix spectre_v1 bug and mitigation indicators (John Haxby) [Orabug: 27470707]
- x86/mitigation/spectre_v2: Add reporting of 'lfence' (Konrad Rzeszutek Wilk)
- x86/spec_ctrl: Add 'nolfence' knob to disable fallback for spectre_v2 mitigation (Konrad Rzeszutek Wilk)
- x86/spectre: Drop the warning about ibrs being obsolete. (Konrad Rzeszutek Wilk)
- x86/spec: Don't print the Missing arguments for option spectre_v2. (Konrad Rzeszutek Wilk)
- x86: Display correct settings for the SPECTRE_V2 bug (Kanth Ghatraju) [Orabug: 27403317]
- x86/cpufeatures: Add X86_BUG_SPECTRE_V[12] (David Woodhouse) [Orabug: 27403317]
- x86: Fix spectre/kpti integration (Konrad Rzeszutek Wilk) [Orabug: 27352353] {CVE-2017-5754}
- x86/spectre_v2: Fix cpu offlining with IPBP. (Konrad Rzeszutek Wilk)
- retpoline: selectively disable IBRS in disable_ibrs_and_friends() (Chuck Anderson) [Orabug: 27636063]
- retpoline: move setting of sysctl_ibrs_enabled and sysctl_ibpb_enabled to where SPEC_CTRL_IBRS_INUSE and SPEC_CTRL_IBPB_INUSE are set (Chuck Anderson) [Orabug: 27556096]
- retpoline: set IBRS and IBPB in use only on the boot CPU call to init_scattered_cpuid_features() (Chuck Anderson) [Orabug: 27556096]
- retpoline: display IBPB feature status along with IBRS status (Chuck Anderson) [Orabug: 27556096]
- retpoline: move lock/unlock of spec_ctrl_mutex to check_modinfo() (Chuck Anderson) [Orabug: 27556096]
- retpoline: call clear_retpoline_fallback() with boot parm spectre_v2_heuristics=off (Chuck Anderson) [Orabug: 27556096]
- retpoline: add brackets to check_ibrs_inuse() and clear_ibpb_inuse() (Chuck Anderson) [Orabug: 27556096]
- retpoline/module: do not enable IBRS/IPBP if SPEC_CTRL_IBRS_ADMIN_DISABLED/SPEC_CTRL_IBPB_ADMIN_DISABLED is set (Chuck Anderson) [Orabug: 27547729]
- retpoline: microcode incorrectly reported as broken during early boot (Chuck Anderson) [Orabug: 27556096]
- retpoline: move lock/unlock of spec_ctrl_mutex into init_scattered_cpuid_features() (Chuck Anderson) [Orabug: 27556096]
- Revert "x86/spec_ctrl: Add 'nolfence' knob to disable fallback for spectre_v2 mitigation" (Konrad Rzeszutek Wilk) [Orabug: 27601790]
- x86/spectre_v2: Fix the documentation to say the right thing. (Konrad Rzeszutek Wilk)
- x86/spectre_v2: Don't check bad microcode versions when running under hypervisors. (Konrad Rzeszutek Wilk) [Orabug: 27601735]
- x86/spectre: move microcode check before kernel ibrs flags are set (Daniel Jordan) [Orabug: 27534557] {CVE-2017-5715}
- retpoline/module: fall back to another spectre mitigation when disabling retpoline (Chuck Anderson) [Orabug: 27457402]
- retpoline/module: add bit defs for use_ibpb (Chuck Anderson) [Orabug: 27457402]
- x86/spectre_v2: Only use IBRS when ibrs_inuse tells us to (Konrad Rzeszutek Wilk)
- x86/spectre_v2: Disable IBRS if spectre_v2=off (Konrad Rzeszutek Wilk)
- x86/spectre_v2: Remove 0xc2 from spectre_bad_microcodes (Darren Kenny) [Orabug: 27523395]
- x86/spectre_v2: Add spectre_v2_heuristics= (Konrad Rzeszutek Wilk) [Orabug: 27478139] {CVE-2017-5715}
- x86/spectre_v2: Do not disable IBPB when disabling IBRS (Konrad Rzeszutek Wilk) [Orabug: 27478139] {CVE-2017-5715}
- x86/spectre: Favor IBRS on Skylake over retpoline (Konrad Rzeszutek Wilk) [Orabug: 27478139] {CVE-2017-5715}
- x86/spectre: Now that we expose 'stbibp' make sure it is correct. (Konrad Rzeszutek Wilk) [Orabug: 27478139] {CVE-2017-5715}
- x86/cpufeatures: Clean up Spectre v2 related CPUID flags (David Woodhouse) [Orabug: 27478139] {CVE-2017-5715}
- x86/spectre_v2: Don't spam the console with these: (Konrad Rzeszutek Wilk) [Orabug: 27478139] {CVE-2017-5715}
- x86/cpufeature: Blacklist SPEC_CTRL/PRED_CMD on early Spectre v2 microcodes (David Woodhouse) [Orabug: 27478139] {CVE-2017-5715}
- x86/spectre_v2: Print what options are available. (Konrad Rzeszutek Wilk) [Orabug: 27478139] {CVE-2017-5715}
- x86/spectre_v2: Add VMEXIT_FILL_RSB instead of RETPOLINE (Konrad Rzeszutek Wilk) [Orabug: 27478139] {CVE-2017-5715}
- x86/spectre: If IBRS is enabled disable "Filling RSB on context switch" (Konrad Rzeszutek Wilk) [Orabug: 27478139] {CVE-2017-5715}
- x86/spectre_v2: Don't allow {ibrs,ipbp,lfence}_enabled to be toggled if retpoline (Konrad Rzeszutek Wilk) [Orabug: 27478139] {CVE-2017-5715}
- x86/spectre: Fix retpoline_enabled (Konrad Rzeszutek Wilk) [Orabug: 27478139] {CVE-2017-5715}
- x86/spectre: Update sysctl values if toggled only by set_{ibrs,ibpb}_disabled (Konrad Rzeszutek Wilk) [Orabug: 27478139] {CVE-2017-5715}
- retpoline/module: Taint kernel for missing retpoline in module (Andi Kleen) [Orabug: 27478139] {CVE-2017-5715}
- x86/retpoline: Fill RSB on context switch for affected CPUs (David Woodhouse) [Orabug: 27478139] {CVE-2017-5715}
- x86/retpoline: Optimize inline assembler for vmexit_fill_RSB (Andi Kleen) [Orabug: 27478139] {CVE-2017-5715}
- retpoline: Introduce start/end markers of indirect thunk (Masami Hiramatsu) [Orabug: 27478139] {CVE-2017-5715}
- x86/retpoline: Add LFENCE to the retpoline/RSB filling RSB macros (Tom Lendacky) [Orabug: 27478139] {CVE-2017-5715}
- x86/retpoline: Remove compile time warning (Thomas Gleixner) [Orabug: 27478139] {CVE-2017-5715}
- x86/retpoline: Fill return stack buffer on vmexit (David Woodhouse) [Orabug: 27478139] {CVE-2017-5715}
- x86/retpoline/irq32: Convert assembler indirect jumps (Andi Kleen) [Orabug: 27478139] {CVE-2017-5715}
- x86/retpoline/checksum32: Convert assembler indirect jumps (David Woodhouse) [Orabug: 27478139] {CVE-2017-5715}
- x86/retpoline/xen: Convert Xen hypercall indirect jumps (David Woodhouse) [Orabug: 27478139] {CVE-2017-5715}
- x86/retpoline/hyperv: Convert assembler indirect jumps (David Woodhouse) [Orabug: 27478139] {CVE-2017-5715}
- x86/retpoline/ftrace: Convert ftrace assembler indirect jumps (David Woodhouse) [Orabug: 27478139] {CVE-2017-5715}
- x86/retpoline/entry: Convert entry assembler indirect jumps (David Woodhouse) [Orabug: 27478139] {CVE-2017-5715}
- x86/retpoline/crypto: Convert crypto assembler indirect jumps (David Woodhouse) [Orabug: 27478139] {CVE-2017-5715}
- x86/spectre_v2: Add disable_ibrs_and_friends (Konrad Rzeszutek Wilk) [Orabug: 27478139] {CVE-2017-5715}
- x86/spectre_v2: Figure out if STUFF_RSB macro needs to be used. (Konrad Rzeszutek Wilk) [Orabug: 27478139] {CVE-2017-5715}
- x86/spectre_v2: Figure out when to use IBRS. (Konrad Rzeszutek Wilk) [Orabug: 27478139] {CVE-2017-5715}
- x86/spectre: Add IBRS option. (Konrad Rzeszutek Wilk) [Orabug: 27478139] {CVE-2017-5715}
- x86/spectre: Add boot time option to select Spectre v2 mitigation (David Woodhouse) [Orabug: 27478139] {CVE-2017-5715}
- x86/retpoline: Add initial retpoline support (David Woodhouse) [Orabug: 27478139] {CVE-2017-5715}
- x86/spec: Fix spectre_v1 bug and mitigation indicators (John Haxby) [Orabug: 27470707]
- x86/mitigation/spectre_v2: Add reporting of 'lfence' (Konrad Rzeszutek Wilk)
- x86/spec_ctrl: Add 'nolfence' knob to disable fallback for spectre_v2 mitigation (Konrad Rzeszutek Wilk)
- x86/spectre: Drop the warning about ibrs being obsolete. (Konrad Rzeszutek Wilk)
- x86/spec: Don't print the Missing arguments for option spectre_v2. (Konrad Rzeszutek Wilk)
- x86: Display correct settings for the SPECTRE_V2 bug (Kanth Ghatraju) [Orabug: 27403317]
- x86/cpufeatures: Add X86_BUG_SPECTRE_V[12] (David Woodhouse) [Orabug: 27403317]
- x86: Fix spectre/kpti integration (Konrad Rzeszutek Wilk) [Orabug: 27352353] {CVE-2017-5754}

[Potato-Matic]

@speed47 I came across this which would seem to shed some light on some above things: https://lkml.org/lkml/2018/3/20/295
Folowing the mail thread, there's this on the subject of userspace-to-userspace mitigation without IBPB (seems it requires a retpoline userspace, since RSB stuffing only affects RETs, if I'm reading the latter messages right):
"The assumption thus far (good or bad) is that everything will get a microcode update. I actually don't know for sure if RSB manipulation is effective on old microcode before Skylake. I'm pretty sure it has not been documented publicly."
EDIT: continued: https://lkml.org/lkml/2018/3/21/839

It seems to me that there is a little bit of work being done on "what do you do if you don't have updated microcode" but reading all the messages it seems to me it's from the standpoint of "IBPB/IBRS are slow" Still, you might draw your own conclusions. At any rate, it's something I found that seems interesting.

[orachas]

If/when I have control over a critical application, I will sink it into a chroot() if possible, either explicitly or through systemd-nspawn.

This is obviously a challenge with an Oracle database instance, but it can be done. I wish the browsers would do it.

POSIX chroot() has been with us since Bell Labs version 7. Everyone whines that it's too hard, which should stop. I wonder what Tails does.

[Potato-Matic]

Looking WAAAY back: https://lkml.org/lkml/2018/1/22/598
"The early part of the series adds the new feature bits and detects when
it can turn KPTI off on non-Meltdown-vulnerable Intel CPUs, and also
supports the IBPB barrier that we need to make retpoline complete. That
much I think we definitely do want. There have been a bunch of us
working on this behind the scenes; one of us will probably post that
bit in the next day or so."

So now I wonder how true this still is (that IBPB is needed for complete retpoline), especially if you've got a bunch of userspace stuff compiled with retpoline.