Dear Alexei and the rest of the community,
I do want to make a note about the concept of the interpreter being
"less secure".
Firstly the interpreter is not contributing that much to the
exploitation of Spectre. While Google Project Zero did say without the
interpreter building the specific exploit they had for Spectre V2
seems "annoying", that is all there is to it, the security benefit of
removing the interpreter is more like an annoyance instead of a
roadblock. It is quite likely that automated tools can find gadgets
that can do the jobs without too much trouble, the only annoying bit
would be the attackers would have to find different gadgets for
differently built kernels.
Granted, removing any unused functionality can be an improvement for a
system's security, and the observation that the interpreter can be
removed without too much pain was quite interesting when the option
was introduced. But in this specific case, the security trade-off here
is a balancing act between two functionalities: JITed BPF and the
interpreter, since removing BPF altogether is probably not an option
in realistic terms. The JITed BPF has more than contributed its fair
share of assistance to various attacks[1-3], including the original
Spectre attacks[4]. So disabling JIT and keeping the interpreter in
place is, security-wise, an even better mitigation, if we had to
remove one of the two paths.
I would argue that keeping the interpreter, especially hardened with
defenses proposed in EPF, is at the very least a competitive option
for security. It enables system admins to disable JIT as
mitigation/prevention against potential risk from the JITed component
of BPF (which is now impossible), while still enjoying the security
enhancement provided by EPF defenses.
If I can have your blessing on the security trade-off, I can move
forward to try to adapt the patches for submission.
Regards,
Di
[1] Reshetova, Elena, Filippo Bonazzi, and N. Asokan. "Randomization
can’t stop BPF JIT spray." In Network and System Security: 11th
International Conference, NSS 2017, Helsinki, Finland, August 21–23,
2017, Proceedings 11, pp. 233-247. Springer International Publishing,
2017.
[2] Nelson, Luke, Jacob Van Geffen, Emina Torlak, and Xi Wang.
"Specification and verification in the field: Applying formal methods
to {BPF} just-in-time compilers in the Linux kernel." In 14th USENIX
Symposium on Operating Systems Design and Implementation (OSDI 20),
pp. 41-61. 2020.
[3] Kirzner, Ofek, and Adam Morrison. "An analysis of speculative type
confusion vulnerabilities in the wild." In 30th USENIX Security
Symposium (USENIX Security 21), pp. 2399-2416. 2021.
[4] Kocher, Paul, Jann Horn, Anders Fogh, Daniel Genkin, Daniel Gruss,
Werner Haas, Mike Hamburg et al. "Spectre attacks: Exploiting
speculative execution." Communications of the ACM 63, no. 7 (2020):
93-101.
