> -----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. Dave
