RE: BPF ISA Security Considerations section

[dthaler1968@googlemail.com]

> -----Original Message-----
> From: dthaler1968@googlemail.com <dthaler1968@googlemail.com>
> Sent: Monday, April 22, 2024 1:26 PM
> To: 'David Vernet' <void@manifault.com>; dthaler1968@googlemail.com
> Cc: bpf@ietf.org; bpf@vger.kernel.org
> Subject: RE: BPF ISA Security Considerations section
> 
> > -----Original Message-----
> > From: David Vernet <void@manifault.com>
> > Sent: Monday, April 22, 2024 12:35 PM
> > To: dthaler1968@googlemail.com
> > Cc: bpf@ietf.org; bpf@vger.kernel.org
> > Subject: Re: BPF ISA Security Considerations section
> >
> > On Mon, Apr 22, 2024 at 11:37:48AM -0700, dthaler1968@googlemail.com
> wrote:
> > > David Vernet <void@manifault.com> 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