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