On Mon, Apr 22, 2024 at 11:37:48AM -0700, dthaler1968@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. Sorry, yes, I meant to say interpreters. What I really meant though is that discussing the safety of JIT engines vs. interpreters seems a bit out of scope for this Security Considerations section. It's not as though JIT is a foolproof method in and of itself. > > Do you have a suggested alternate wording? How about this: 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 and JIT engines can be a source of insecurity (e.g., gadgets susceptible to side-channel attacks due to speculative execution, or W^X mappings), and should be audited carefully for vulnerabilities. > 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. This is fine too. My only worry is that there have also been plenty of vulnerabilities exploited against JIT engines as well, so it might be more prudent to just warn the reader of the risks of interpreters/JITs in general as opposed to prescribing one over the other. What do you think? Thanks, David
Attachment:
signature.asc
Description: PGP signature
-- Bpf mailing list Bpf@xxxxxxxx https://www.ietf.org/mailman/listinfo/bpf
