Re: [Bpf] BPF ISA Security Considerations section

[David Vernet <void@manifault.com>]

[-- Attachment #1: Type: text/plain, Size: 3186 bytes --]

On Tue, Apr 23, 2024 at 10:59:09AM -0700, dthaler1968@googlemail.com 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 #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]