RE: BPF ISA Security Considerations section

[dthaler1968@googlemail.com]

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

Dave