6

Why Xen wasn't hit by RETBleed on Intel CPUs

 2 years ago
source link: https://xcp-ng.org/blog/2022/08/26/why-xen-wasnt-hit-by-retbleed-on-intel-cpus/
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
neoserver,ios ssh client

Why Xen wasn't hit by RETBleed on Intel CPUs

Security • Aug 26, 2022

You probably heard about RETBleed security issue. Almost all operating systems had to release patches regarding this new hardware vulnerability. See our previous blog post about it:

retbleed.jpg

But why Xen did release a fix only for AMD CPUs while Intel seems to be also hit? The answer is very interesting and another proof that Xen Project is taking security VERY seriously.

Security is hard

For example, on Linux kernel, both Intel and AMD CPUs were impacted, as you can read here: CVE-2022-29900 (AMD) and CVE-2022-29901 (Intel).

In the Xen security bulletin, only CVE-2022-29900 was fixed. What about CVE-2022-29901 on Intel side?

RETBleed on Intel isn't in fact a new hardware issue. It's a consequence of choices made by some OSes 4 years ago (including Linux), when Spectre-like speculation issues started to be known. To understand a bit more about it, we need first to talk about the first mitigation to those speculation issues: reptolines. They were introduced in 2018, as one possible mitigation against Spectre v2 speculative execution attacks.

NewTux.svg.png

Retpoline concept

To mitigate speculation/side-channel issues, there's mainly 2 options:

  • direct manipulation on the hardware level (requiring CPU microcode updates)
  • rewriite software such that it doesn't use the problematic predictor.

So in the end, retpoline is primarily a software construct where specific knowledge on the hardware is needed to mitigate branch target injection.

retpoline.png
Retpoline concept, from Intel documentation

Are retpolines enough to stop speculative executions attack? Well, it's not, and RETBleed is the living proof of it. Despite some public warning inside the Linux project (4 years ago) about the insufficient capability of retpolines to protect against those attacks in some configurations, and even suggesting other solutions to fix it (see below), it was decided to left it "as is".

Mostly because people didn't believe that it was possible to exploit the retpoline limitations. As we seen, it was more a belief than a true statement.

So is there other solutions to protect against these attacks? Yes, using IBRS!

IBRS to the rescue

So when retpolines aren't safe, there is indeed another possibility to protect yourself from speculation attacks: using IBRS. Another acronym, yay! IBRS means "Indirect Branch Restricted Speculation". This is an Intel CPU specific feature, restricting speculation of indirect branches, and therefore protecting indirect branch predictions.

So why not using it for everything? Well, there's multiple reasons:

  • it's a kind of "retrofit" added in the microcode, not originally a native/hardware mitigation (in Skylake CPUs): it is very SLOW compared to retpoline 🐌
  • it's harder to implement than just doing retpolines from the hypervisor or operating system perspective 👷

That's likely why other projects/OSes decided to not use it… until RETBleed!

eIBRS: since IBRS was very slow and a kind of a "hack", Intel added Enhanced IBRS (eIBRS) since Cascade Lake generation: you can see it as the "hardware implementation" of IBRS, which was microcode only. Skylake and previous generations are doomed to be slow and to rely only on IBRS to be "safe".

If you want to read more about IBRS and eIBRS, you can directly read the Intel official documentation.

Xen Project and security

However, security (and not leaking your data to anyone), is more important than those previous considerations. That's why Xen project didn't left the hypervisor with incomplete mitigations for 4 years, and decided to use IBRS when it was crucial, despite the performance hit when used by the virtual machine on top of it.

The approach in Xen was to virtualize and expose MSR_SPEC_CTRL to the guest operating system. This way, even Windows system could rely on their own code to call IBRS when needed (which is the case). That's why IBRS was exposed to guests back in 2018 (XSA 263).

All of this explains why the latest Xen Security Advisory (XSA) 407 was only about AMD:

On Intel CPUs, Retbleed is not a new vulnerability; it is only applicable to software which did not follow Intel's original Spectre-v2 guidance.

This is a great demonstration that Xen Project is taking security very seriously, as we also do here for XCP-ng. By the way, if you are still not convinced, you can have a read on https://xenproject.org/users/security.

Frankly, Xen is probably the best Open Source project I know in terms of taking security seriously. If you are interested to learn more about how Xen Project is working on deep security issues, let us know, we'll be happy to go deeper and even get some Xen core developers interviews!


report

Recommend

About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK