On Tue, Apr 23, 2024 at 10:59:09AM -0700, dthaler1968@xxxxxxxxxxxxxx wrote: > 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. LGTM
Attachment:
signature.asc
Description: PGP signature
