> -----Original Message----- > From: David Vernet <void@xxxxxxxxxxxxx> > Sent: Sunday, April 21, 2024 9:52 AM > To: dthaler1968@xxxxxxxxxxxxxx > Cc: bpf@xxxxxxxx; bpf@xxxxxxxxxxxxxxx > Subject: Re: BPF ISA Security Considerations section > > On Sat, Apr 20, 2024 at 09:08:56AM -0700, dthaler1968@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: > > Hi Dave, > > Thanks for writing this up. Overall it looks great, just had one comment below. > > > > 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. > > > > > > Executing programs using the BPF instruction set also requires > > > either an interpreter or a JIT 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) and are not > > > recommended. > > Do we need to say that it's not recommended to use JIT engines? Given that this is > explaining how BPF programs are executed, to me it reads a bit as saying, "It's not > recommended to use BPF." Is it not sufficient to just explain the risks? It says it's not recommended to use interpreters. I couldn't tell if your comment was a typo, did you mean interpreters or JIT engines? It should read as saying it's recommended to use a JIT engine rather than an interpreter. Do you have a suggested alternate wording? Dave
