On Wed, Jan 03, 2024 at 04:06:32PM +0000, Maxwell Bland wrote: > Forwarding to BPF mailing list as plaintext to match the mail server restrictions. > > From what I understand, Linux security team is reactive rather than > proactive, so maybe the below is a moot point, but I'd love to see > BPF-NX+CFI if possible. security@xxxxxxxxxx is reactive, as that is it's requirement, but there are many other groups that work on proactive security, see the linux-hardening project for lots of work happening there that is adding loads of good stuff to the kernel. > > Originally sent to di_jin@xxxxxxxxx; v.atlidakis@xxxxxxxxx; vpk@xxxxxxxxxxxx; dborkman@xxxxxxxxxx; lsf-pc@xxxxxxxxxxxxxxxxxxxxxxxxxx; bpf@xxxxxxxxxxxxxxx; Andrew Wheeler <awheeler@xxxxxxxxxxxx>; Sammy BS2 Que | 阙斌生 <quebs2@xxxxxxxxxxxx> > > Dear Jin et al. Daniel Borkman, and LSF/BPF mailing lists, > > Although a few months late, Jin et al.’s USENIX ATC’23 EPF publication here (https://cs.brown.edu/~vpk/papers/epf.atc23.pdf) is great. It was a relief to see the efforts in https://gitlab.com/brown-ssl/epf/-/blob/master/linux-5.10/patches/0003-Adding-BPF-NX.patch?ref_type=heads and related files. > > BPF-NX+CFI would/could/should be a great upstreaming candidate. I am not sure how well BPF-NX+CFI generalizes to the full kernel ecosystem given the approach requires a dedicated vmalloc memory region, but the idea PXN is no longer be enforced at a PMD-level granularity because of eBPF is unfortunate. > > BPF-ISR is likely overkill performance-wise as a mechanism and can be handled/refined via kprobes rather than direct patches. > > Jin et al., do you happen to have performance numbers for just NX+CFI, or knowledge of how well this may apply to 6.*+ kernels? With your blessing, and if the mailing list peers are supportive, we should discuss your work and BPF security at https://events.linuxfoundation.org/lsfmmbpf/program/cfp/. Are there working patches somewhere? 5.10.y is very old and obsolete. thanks, greg k-h
