Re: [EXTERNAL] Re: [Bpf] BPF ISA Security Considerations section

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Linux Samsung SoC]     [Linux Rockchip SoC]     [Linux Actions SoC]     [Linux for Synopsys ARC Processors]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]


  Powered by Linux