> -----Original Message----- > From: Alexei Starovoitov <alexei.starovoitov@xxxxxxxxx> > Sent: Wednesday, January 3, 2024 7:42 PM > To: Maxwell Bland <mbland@xxxxxxxxxxxx> > Cc: Jin, Di <di_jin@xxxxxxxxx>; 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 > > 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.ke/ > rnel.org%2Fbpf%2FSEZPR03MB678610EEBA5140BAA4D1F13EB4602%40SEZP > R03MB6786.apcprd03.prod.outlook.com%2F&data=05%7C02%7Cmbland%40 > motorola.com%7C119f36d06aa949e8c53d08dc0cc6584f%7C5c7d0b28bdf8410 > caa934df372b16203%7C0%7C0%7C638399293224490892%7CUnknown%7CT > WFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJ > XVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=0nYYLCmyd2muUy3RMFbH1Cqn > Gq%2Bs8682geAHnwIBTO0%3D&reserved=0. 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. Ugh, stupid typo---there is no excuse, apologies. The benefit of https://lore.kernel.org/bpf/SEZPR03MB6786B27446DE261893D911B5B4602@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/ to me is not in the interpreter changes but in the separation of BPF code pages from the rest of the vmalloc region. Without this, one hypothetically would need to know which PTEs are BPF-owned so they know which PTEs' X bits are (not) malicious. (-; Unfortunately, that is all I can say for now. Targeting ARM+x86. If this is OK justification (I do not know it will be), myself or Di Jin could submit another patch with the interpreter portions removed? Peter Zijlstra's CFI patches for x86 look like a reasonable approach to the CFI side. https://lore.kernel.org/bpf/20231215092707.231038174@xxxxxxxxxxxxx/T/ I imagine ARM would likely follow suit. Maybe Peter can weigh in on the plans here and ideas above, since it looks like Intel also wants BPF hardening. Hopefully not totally off base here and hopefully typo-free. Here’s to the community, and thank you. Maxwell Bland
