On Sat, Apr 20, 2024 at 9:09 AM <dthaler1968=40googlemail.com@xxxxxxxxxxxxxx> wrote: > > Per https://authors.ietf.org/en/required-content#security-considerations, > the BPF ISA draft is required to have a Security Considerations section > before > it can become an RFC. > > Below is strawman text that tries to strike a balance between discussing > security issues and solutions vs keeping details out of scope that belong in > other > documents like the "verifier expectations and building blocks for allowing > safe > execution of untrusted BPF programs" document that is a separate item on the > IETF WG charter. > > Proposed text: > > > 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 or > 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. The details are out of scope of this > document > > (but see [LINUX] and [PREVAIL]), but this level of verification can often > provide a > > stronger level of security assurance than for other software and operating > system > > code. I would put a reference to the other deliverable to say more. If we think that's suboptimal for publication strategy, maybe we can be more generic about it. Often BPF programs are executed on the other side of a reliability boundary, e.g. if you execute a BPF filter saying drop all on your network card, have fun. This isn't different from firewalls and the like, but it's a new risk that people aren't expecting. I think we might also need to call out that BPF security assurance requires careful design and thought about what is exposed via BPF. Sincerely, Watson > Bpf@xxxxxxxx > https://www.ietf.org/mailman/listinfo/bpf -- Astra mortemque praestare gradatim
