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. 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/. Maxwell Bland Motorola
