On Mon, Apr 22, 2024 at 11:38 AM <dthaler1968=40googlemail.com@xxxxxxxxxxxxxx> wrote: > > 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. I am very confused about the substance of this recommendation. I've also got other comments, but will put those in separate reply. Simply put JITs aren't magic. Whether a bounds check is put in by a compiler or an interpreter executes it directly, it can still be speculatively bypassed. If anything JITs may simplify the matter compared to interpreters as the execution path maps more closely to the BPF executed, and the BPF will have tighter control of paths and layout if e.g. it is injecting branches to fool the CPU later. There's a wide range of execution technologies that go under the name JIT and interpreter, from threaded code to complete compilation to trace based compilation with bailouts to even more complex schemes. All of them have Specter issues. Sincerely, Watson Ladd > > Dave > > -- > Bpf mailing list > Bpf@xxxxxxxx > https://www.ietf.org/mailman/listinfo/bpf -- Astra mortemque praestare gradatim
