On Mon, Apr 22, 2024 at 1:32 PM <dthaler1968=40googlemail.com@xxxxxxxxxxxxxx> wrote: > > > -----Original Message----- > > From: dthaler1968@xxxxxxxxxxxxxx <dthaler1968@xxxxxxxxxxxxxx> > > Sent: Monday, April 22, 2024 1:26 PM > > To: 'David Vernet' <void@xxxxxxxxxxxxx>; dthaler1968@xxxxxxxxxxxxxx > > Cc: bpf@xxxxxxxx; bpf@xxxxxxxxxxxxxxx > > Subject: RE: BPF ISA Security Considerations section > > > > > -----Original Message----- > > > From: David Vernet <void@xxxxxxxxxxxxx> > > > Sent: Monday, April 22, 2024 12:35 PM > > > To: dthaler1968@xxxxxxxxxxxxxx > > > Cc: bpf@xxxxxxxx; bpf@xxxxxxxxxxxxxxx > > > Subject: Re: BPF ISA Security Considerations section > > > > > > 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. > > > > I've had security researchers tell me that using an interpreter in the > same address > > space as other confidential data is inherently a vulnerability, i.e., no > one can prove > > that it's not a side channel attack waiting to happen and all evidence is > that it cannot > > be protected. Only an interpreter in a separate address space from any > secrets can > > be safe in that respect. So I believe just saying that interpreters > "should be audited > > carefully for vulnerabilities" would not pass security muster by such > folks. > > > > > > 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? > > > > I think the "should be audited carefully for vulnerabilities" phrase would > apply to JITs > > for sure. However it would also apply to any non-BPF code in a privileged > context > > such as a kernel, so it would seem odd to call it out here and not in all > other RFCs > > that would apply to kernel code (e.g., TCP/IP). But if others really want > that, we > > could certainly say that. > > Updated proposed text, based on David's and Watson's feedback: > > 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, > or W^X mappings) whenever one is used in the same memory address space as > data with confidentiality > concerns. As such, use of a JIT compiler is recommended instead. JIT > compilers should be audited > carefully for vulnerabilities to ensure that JIT compilation of a trusted > and verified BPF program > does not introduce vulnerabilities. But W^X mappings are for JIT (and avoidable by writing, then remapping and executing), not interpreters. How about we just say "Executing the program requires an interpreter or JIT compiler in the same memory space as the system being probed or extended. This creates risks of transient execution attacks that can reveal data with confidentiality concerns. Methods for avoiding these attacks are under active research and frequently depend on microarchitectural details." Sincerely, Watson > > Dave > > -- > Bpf mailing list > Bpf@xxxxxxxx > https://www.ietf.org/mailman/listinfo/bpf -- Astra mortemque praestare gradatim
