RE: [Bpf] BPF ISA Security Considerations section

[dthaler1968@googlemail.com]

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.