> -----Original Message-----
> From: Jin, Di <di_jin@xxxxxxxxx>
> Sent: Thursday, January 4, 2024 8:02 PM
> To: Alexei Starovoitov <alexei.starovoitov@xxxxxxxxx>
> Cc: Maxwell Bland <mbland@xxxxxxxxxxxx>; bpf@xxxxxxxxxxxxxxx;
> v.atlidakis@xxxxxxxxx; vpk@xxxxxxxxxxxx; Andrew Wheeler
> <awheeler@xxxxxxxxxxxx>; Sammy BS2 Que | 阙斌生
> <quebs2@xxxxxxxxxxxx>
> Subject: Re: [External] Fwd: BPF-NX+CFI is a good upstreaming candidate
>
> 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.
A critical subtext is that many/most security-conscious builds (Google's Android GKI, iirc) have JIT always enabled.
After I made that typo that switched up enabled/disabled in the chain yesterday, Alexei thankfully noted "the presence of _any_ interpreter in the kernel text is a problem regardless of whether JIT-ing is enabled or not". JIT having problems doesn't imply that an interpreter will not have issues of its own. Interpreters bugs can lead to more security problems rather than fewer, Spectre or otherwise, resulting in the necessity of a critical general commitment to maintaining and vetting the interpreter within the kernel. Major players like Intel and Google seem to have unofficially committed to JIT maintenance and security instead. There are some good arguments for this on the non-security side.
With the inclusion of Peter's CFI patches and the adaption of these to ARM, there's already strong progress towards security for BPF's JIT. If the mixing executable code with data issue gets fixed too, then it will soon become possible to treat BPF JIT programs like any other part of the .text section, which seems like a huge win, since BPF then gets all or many of the fruits of standard .text section security.
Regards,
Maxwell Bland
