> -----Original Message-----
> From: Maxwell Bland <mbland@xxxxxxxxxxxx>
> Sent: Friday, January 5, 2024 10:59 AM
> To: Jin, Di <di_jin@xxxxxxxxx>; Alexei Starovoitov
> <alexei.starovoitov@xxxxxxxxx>
> Cc: 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
>
> > -----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
Forget that last point "mixing executable code..." (in ARM).
In v6.4-rc3 Mark Rutland fixed the issue: https://lore.kernel.org/linux-arm-kernel/20230530110328.2213762-1-mark.rutland@xxxxxxx/
I.e the BPF code in vmalloc range issue is only in Android. Will bring up BPF-NX to Google. Looking forward to Peter's CFI patches!
Thanks,
Maxwell Bland
