> -----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. An architecture-independent implementation would also be a nice-to-have and address the CONFIG_RANDOMIZE_MEMORY issue, requiring some additional work with vmalloc to provide agnostic segmentation between the allocation of kernel-privileged code and data. Also, feel free to reach out to me directly with any questions, so as to not crowd the mailing list. Regards, Maxwell Bland
