Some folks have noticed the following scary eBPF warning in their logs:
Spectre V2 : WARNING: Unprivileged eBPF is enabled with eIBRS on, data leaks possible via Spectre v2 BHB attacks!
Spectre! Unprivileged! Data leaks! Attacks!
TL;DR: You can ignore it
Basically, a bunch of alarming keywords that should make anyone sit up and take immediate notice. It’s scary looking, but, ultimately harmless for pretty much everyone and you can ignore it. But don’t just take our word for it: read on and we’ll explain why.
I like to define things first. Feel free to skip ahead.
eBPF is the extended Berkley Packet Filter. You can read more on the eBPF community site (What is eBPF? An Introduction and Deep Dive into the eBPF Technology) but, in summary, eBPF allows you to dynamically instrument a system’s runtime kernel. The low-level access eBPF grants is incredibly useful for performing nifty network routing tricks, enhancing observability and security, aiding debugging, the list goes on. It’s safe and performant and just a Good Thing. BUT if you’re instrumenting the kernel, that means basically unrestricted access to everything the system can read or do. So you probably wouldn’t want to let users run their own arbitrary eBPF programs. But you might want to let users run some eBPF programs and that’s what unprivileged eBPF is: it allows an unprivileged user on the system to load certain eBPF programs, albeit with reduced functionality and limited access to the kernel.
eIBRS is extended Indirect Branch Restricted Speculation. As much as I would love to take a stab at explaining speculative execution vulnerability mitigations, it would probably take way too long (and I’d likely screw it up). Suffice it to say, eIBRS was a processor microcode update from Intel to fix the Spectre speculative execution attack.
Spectre (and Meltdown) were the OG speculative execution vulns. Basically, folks figured they could make processors faster by executing multiple potential processor instruction flows/branches in advance of knowing which flow would actually be needed. The results of computation would thus be more readily available once the determination of the needed flow was complete, and the unused branches could be discarded. This “compute it all and throw away what you don’t need” approach led to detectable side effects, which led to timing attacks, which led to data leaks, which led to me hating Blackhat and the launch of that year’s batch of terrible speculative execution bugs that we have to be freaked out about. Anyway…
Spectre v2 is a nastier version of Spectre. Timing attacks and data leaks? That’s so v1. How about just causing the processor to jump to attacker controlled code (aka Branch Target Injection)? Now we’re talking! This is what eIBRS attempts to prevent: blocking jumping from one privilege level branch to a lower privilege level branch. eIBRS tracks the various branches and privilege levels via the Branch History Buffer (BHB). All well and good but, while an attacker can’t inject branch targets anymore, they can poison the BHB to cause jumps to attacker selected branch targets. Still game over, in other words.
Summary: Initially, the only known real-world BHB attack vector was via unprivileged eBPF (though other attack vectors have since been found that don’t require unprivileged eBPF). So this is what the warning is saying: within the restricted set of functionality available to unprivileged eBPF programs there remains the ability to poison the BHB to cause the processor to branch to attacker-selected branches of code.
Still sounds bad, right? Well, not quite. Technically, if you were running a Fly Machine that ran untrusted BPF code from your own users AND you gave them shell access, you might have a problem. So just don’t do that.
Our advice is: if you’re running untrusted code from a user, you should start it in its own little Fly Machine, and not care about whether that code could take over the Machine kernel, because you’re just going to throw it away when it’s done.
Conclusion: Don’t freak out about the message. It’s full of sound and fury, signifying nothing.
(Also, the warning may go away over time: unprivileged eBPF is already disabled in some mainstream distros and I expect our VM kernel will likely join the crowd at some point.)