>From: Bpf <bpf-bounces@xxxxxxxx> on behalf of Watson Ladd <watsonbladd@xxxxxxxxx> >Sent: Monday, April 22, 2024 5:19 PM >To: dthaler1968=40googlemail.com@xxxxxxxxxxxxxx <dthaler1968=40googlemail.com@xxxxxxxxxxxxxx> >Cc: dthaler1968@xxxxxxxxxxxxxx <dthaler1968@xxxxxxxxxxxxxx>; David Vernet <void@xxxxxxxxxxxxx>; bpf@xxxxxxxx <bpf@xxxxxxxx>; bpf@xxxxxxxxxxxxxxx <bpf@xxxxxxxxxxxxxxx> >Subject: [EXTERNAL] Re: [Bpf] BPF ISA Security Considerations section > >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." Is it strictly true that BPF implies either JIT or interpreter? The eBPF for Windows project does ahead of time compilation (AOT), through a process of translating each BPF instruction into an equivalent C statement and then passing it through a C compiler to produce side-channel aware code (and also permit post verification optimization). I believe interpreter or JIT are implementation details and not intrinsic to the ISA. Regards, Alan Jowett > >Sincerely, >Watson >> >> Dave >> >> -- >> Bpf mailing list >> Bpf@xxxxxxxx >> https://www.ietf.org/mailman/listinfo/bpf > > > >-- >Astra mortemque praestare gradatim > >-- >Bpf mailing list >Bpf@xxxxxxxx >https://www.ietf.org/mailman/listinfo/bpf >
