On Wed, Jan 3, 2024 at 3:45 PM Maxwell Bland <mbland@xxxxxxxxxxxx> wrote: > > > -----Original Message----- > > From: Jin, Di <di_jin@xxxxxxxxx> > > Sent: Wednesday, January 3, 2024 4:39 PM > > To: bpf@xxxxxxxxxxxxxxx > > Subject: [External] Fwd: BPF-NX+CFI is a good upstreaming candidate > > > > ---------- Forwarded message --------- > > From: Jin, Di <di_jin@xxxxxxxxx> > > Date: Wed, Jan 3, 2024 at 5:19 PM > > Subject: Re: BPF-NX+CFI is a good upstreaming candidate > > To: Maxwell Bland <mbland@xxxxxxxxxxxx> > > Cc: v.atlidakis@xxxxxxxxx <v.atlidakis@xxxxxxxxx>, vpk@xxxxxxxxxxxx > > <vpk@xxxxxxxxxxxx>, dborkman@xxxxxxxxxx <dborkman@xxxxxxxxxx>, lsf- > > pc@xxxxxxxxxxxxxxxxxxxxxxxxxx <lsf-pc@xxxxxxxxxxxxxxxxxxxxxxxxxx>, > > bpf@xxxxxxxxxxxxxxx <bpf@xxxxxxxxxxxxxxx>, Andrew Wheeler > > <awheeler@xxxxxxxxxxxx>, Sammy BS2 Que | 阙斌生 > > <quebs2@xxxxxxxxxxxx> > > > > > > Dear all, > > > > There are a couple of noteworthy things about the patches: > > 1. They currently don't work with CONFIG_RANDOMIZE_MEMORY, which > > should probably be addressed. > > 2. BPF-CFI tries to ensure the interpreter starts from the correct offset under > > code-reuse attacks, which means it needs some form of control flow integrity. > > Here we are enforcing that with the state of a read-only variable, which is > > toggled by temporarily disabling the WP bit. This also introduces the problem > > of having to disable interrupt during the interpreter's execution otherwise the > > variable will be in the wrong state during interrupt. In the paper we optimized > > away the toggling of the WP bit by some trick involving turning off protection > > like SMAP during the interpreter's execution, which is faster in terms of > > performance, but the security trade-off is a bit more subtle. The argument > > being that SMAP (or PAN) are contributing very marginally when BPF > > programs are being executed, since the things they are defending against, > > namely user-controlled memory content, are already present in the execution > > context. This version of BPF-CFI should incur almost no overhead. The WP bit > > toggling version I don't have numbers at hand. > > > > @Maxwell: If you are not in a hurry (I will need a couple of days) I can > > generate a set of patches that are compatible for patch submission (proper > > name and email address, signoff, formatting, etc.), during which I can also get > > some performance numbers. We can discuss authorship depending on how > > much you want to adapt these patches. > > > > Regards, > > Di Jin > > Hi Di Jin, > > Thanks! I sent some formatted patches for review a bit earlier today. See https://lore.kernel.org/bpf/SEZPR03MB678610EEBA5140BAA4D1F13EB4602@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/. There was great feedback from Alexei Starovoitov on the issue of Spectre effecting the interpreter when JIT is enabled, so there is a mutual conflict with any hardening options which disable JIT. This seems to be a major barrier. Not quite. The presence of _any_ interpreter in the kernel text is a problem regardless of whether JIT-ing is enabled or not. In bpf case we can always use JIT and remove the interpreter from vmlinux. Hence "JIT always on" is a security fix.
