David Vernet <void@xxxxxxxxxxxxx> wrote: > > 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? How about: OLD: In general, interpreters are considered a OLD: source of insecurity (e.g., gadgets susceptible to side-channel attacks due to speculative execution) OLD: and are not recommended. NEW: In general, interpreters are considered a NEW: source of insecurity (e.g., gadgets susceptible to side-channel attacks due to speculative execution) NEW: so use of a JIT compiler is recommended instead. Dave
