Thanks Watson and Alan for continued feedback. Watson wrote: > But W^X mappings are for JIT (and avoidable by writing, then remapping and > executing), not interpreters. Removed W^X phrase. > How about we just say "Executing the program requires > an interpreter or JIT compiler in the same memory space as the system being > probed or extended. Execution does not require that the interpreter or JIT compiler is in the same memory space, even if that is the most common implementation. (And Alan's point also applies here that compilation might or might not be JIT per se.) Below is the latest strawman after taking the latest feedback into account... -Dave Security Considerations ======================= BPF programs could use BPF instructions to do malicious things with memory, CPU, networking, or other system resources. This is not fundamentally different from any other type of software that may run on a device. Execution environments should be carefully designed to only run BPF programs that are trusted and verified, and sandboxing and privilege level separation are key strategies for limiting security and abuse impact. For example, BPF verifiers are well-known and widely deployed and are responsible for ensuring that BPF programs will terminate within a reasonable time, only interact with memory in safe ways, and adhere to platform-specified API contracts. This level of verification can often provide a stronger level of security assurance than for other software and operating system code. While the details are out of scope of this document, `Linux <https://www.kernel.org/doc/html/latest/bpf/verifier.html>`_ and `PREVAIL <https://pldi19.sigplan.org/details/pldi-2019-papers/44/Simple-and-Precise-Static-Analysis-of-Untrusted-Linux-K Kernel-Extensions>`_ do provide many details. Future IETF work will document verifier expectations and building blocks for allowing safe execution of untrusted BPF programs. Executing programs using the BPF instruction set also requires either an interpreter or a compiler to translate them to hardware processor native instructions. In general, interpreters are considered a source of insecurity (e.g., gadgets susceptible to side-channel attacks due to speculative execution) whenever one is used in the same memory address space as data with confidentiality concerns. As such, use of a compiler is recommended instead. Compilers should be audited carefully for vulnerabilities to ensure that compilation of a trusted and verified BPF program to native processor instructions does not introduce vulnerabilities. Exposing functionality via BPF extends the interface between the component executing the BPF program and the component submitting it. Careful consideration of what functionality is exposed and how that impacts the security properties desired is required.
