BPF ISA Security Considerations section

BPF ISA Security Considerations section

[dthaler1968]

Per https://authors.ietf.org/en/required-content#security-considerations,
the BPF ISA draft is required to have a Security Considerations section
before
it can become an RFC.

Below is strawman text that tries to strike a balance between discussing
security issues and solutions vs keeping details out of scope that belong in
other
documents like the "verifier expectations and building blocks for allowing
safe
execution of untrusted BPF programs" document that is a separate item on the
IETF WG charter.

Proposed text:

> 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.
>
> Informative References:
>
> [LINUX] "eBPF verifier",
https://www.kernel.org/doc/html/latest/bpf/verifier.html
>
> [PREVAIL] Elazar Gershuni, Nadav Amit, Arie Gurfinkel, Nina Narodytska,
Jorge
>    A. Navas, Noam Rinetzky, Leonid Ryzhyk, and Mooly Sagiv. "Simple and
Precise
>    Static Analysis of Untrusted Linux Kernel Extensions." In Proceedings
of the 40th
>    ACM SIGPLAN Conference on Programming Language Design and
Implementation,
>    pp. 1069-1084. 2019.
>
https://pldi19.sigplan.org/details/pldi-2019-papers/44/Simple-and-Precise-St
atic-Analysis-of-Untrusted-Linux-Kernel-Extensions

Dave

[Bpf] BPF ISA Security Considerations section

[dthaler1968=40googlemail.com]

Per https://authors.ietf.org/en/required-content#security-considerations,
the BPF ISA draft is required to have a Security Considerations section
before
it can become an RFC.

Below is strawman text that tries to strike a balance between discussing
security issues and solutions vs keeping details out of scope that belong in
other
documents like the "verifier expectations and building blocks for allowing
safe
execution of untrusted BPF programs" document that is a separate item on the
IETF WG charter.

Proposed text:

> 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.
>
> Informative References:
>
> [LINUX] "eBPF verifier",
https://www.kernel.org/doc/html/latest/bpf/verifier.html
>
> [PREVAIL] Elazar Gershuni, Nadav Amit, Arie Gurfinkel, Nina Narodytska,
Jorge
>    A. Navas, Noam Rinetzky, Leonid Ryzhyk, and Mooly Sagiv. "Simple and
Precise
>    Static Analysis of Untrusted Linux Kernel Extensions." In Proceedings
of the 40th
>    ACM SIGPLAN Conference on Programming Language Design and
Implementation,
>    pp. 1069-1084. 2019.
>
https://pldi19.sigplan.org/details/pldi-2019-papers/44/Simple-and-Precise-St
atic-Analysis-of-Untrusted-Linux-Kernel-Extensions

Dave

-- 
Bpf mailing list
Bpf@ietf.org
https://www.ietf.org/mailman/listinfo/bpf

Re: BPF ISA Security Considerations section

[David Vernet]

[-- Attachment #1: Type: text/plain, Size: 2356 bytes --]

On Sat, Apr 20, 2024 at 09:08:56AM -0700, dthaler1968@googlemail.com wrote:
> Per
> https://authors.ietf.org/en/required-content#security-considerations,
> the BPF ISA draft is required to have a Security Considerations
> section before it can become an RFC.
> 
> Below is strawman text that tries to strike a balance between
> discussing security issues and solutions vs keeping details out of
> scope that belong in other documents like the "verifier expectations
> and building blocks for allowing safe execution of untrusted BPF
> programs" document that is a separate item on the IETF WG charter.
> 
> Proposed text:

Hi Dave,

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?

Thanks,
David

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [Bpf] BPF ISA Security Considerations section

[David Vernet]

[-- Attachment #1.1: Type: text/plain, Size: 2356 bytes --]

On Sat, Apr 20, 2024 at 09:08:56AM -0700, dthaler1968@googlemail.com wrote:
> Per
> https://authors.ietf.org/en/required-content#security-considerations,
> the BPF ISA draft is required to have a Security Considerations
> section before it can become an RFC.
> 
> Below is strawman text that tries to strike a balance between
> discussing security issues and solutions vs keeping details out of
> scope that belong in other documents like the "verifier expectations
> and building blocks for allowing safe execution of untrusted BPF
> programs" document that is a separate item on the IETF WG charter.
> 
> Proposed text:

Hi Dave,

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?

Thanks,
David

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

[-- Attachment #2: Type: text/plain, Size: 76 bytes --]

-- 
Bpf mailing list
Bpf@ietf.org
https://www.ietf.org/mailman/listinfo/bpf

RE: BPF ISA Security Considerations section

[dthaler1968]

> -----Original Message-----
> From: David Vernet <void@manifault.com>
> Sent: Sunday, April 21, 2024 9:52 AM
> To: dthaler1968@googlemail.com
> Cc: bpf@ietf.org; bpf@vger.kernel.org
> Subject: Re: BPF ISA Security Considerations section
> 
> On Sat, Apr 20, 2024 at 09:08:56AM -0700, dthaler1968@googlemail.com
wrote:
> > Per
> > https://authors.ietf.org/en/required-content#security-considerations,
> > the BPF ISA draft is required to have a Security Considerations
> > section before it can become an RFC.
> >
> > Below is strawman text that tries to strike a balance between
> > discussing security issues and solutions vs keeping details out of
> > scope that belong in other documents like the "verifier expectations
> > and building blocks for allowing safe execution of untrusted BPF
> > programs" document that is a separate item on the IETF WG charter.
> >
> > Proposed text:
> 
> Hi Dave,
> 
> 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.

Do you have a suggested alternate wording?

Dave

Re: [Bpf] BPF ISA Security Considerations section

[dthaler1968=40googlemail.com]

> -----Original Message-----
> From: David Vernet <void@manifault.com>
> Sent: Sunday, April 21, 2024 9:52 AM
> To: dthaler1968@googlemail.com
> Cc: bpf@ietf.org; bpf@vger.kernel.org
> Subject: Re: BPF ISA Security Considerations section
> 
> On Sat, Apr 20, 2024 at 09:08:56AM -0700, dthaler1968@googlemail.com
wrote:
> > Per
> > https://authors.ietf.org/en/required-content#security-considerations,
> > the BPF ISA draft is required to have a Security Considerations
> > section before it can become an RFC.
> >
> > Below is strawman text that tries to strike a balance between
> > discussing security issues and solutions vs keeping details out of
> > scope that belong in other documents like the "verifier expectations
> > and building blocks for allowing safe execution of untrusted BPF
> > programs" document that is a separate item on the IETF WG charter.
> >
> > Proposed text:
> 
> Hi Dave,
> 
> 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.

Do you have a suggested alternate wording?

Dave

-- 
Bpf mailing list
Bpf@ietf.org
https://www.ietf.org/mailman/listinfo/bpf

RE: BPF ISA Security Considerations section

[dthaler1968]

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.
> 
> Do you have a suggested alternate wording?

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.

Dave

Re: [Bpf] BPF ISA Security Considerations section

[dthaler1968=40googlemail.com]

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.
> 
> Do you have a suggested alternate wording?

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.

Dave

-- 
Bpf mailing list
Bpf@ietf.org
https://www.ietf.org/mailman/listinfo/bpf

Re: [Bpf] BPF ISA Security Considerations section

[Watson Ladd]

On Mon, Apr 22, 2024 at 11:38 AM
<dthaler1968=40googlemail.com@dmarc.ietf.org> 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.
> >
> > Do you have a suggested alternate wording?
>
> 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.

I am very confused about the substance of this recommendation. I've
also got other comments, but will put those in separate reply.

Simply put JITs aren't magic. Whether a bounds check is put in by a
compiler or an interpreter executes it directly, it can still be
speculatively bypassed. If anything JITs may simplify the matter
compared to interpreters as the execution path maps more closely to
the BPF executed, and the BPF will have tighter control of paths and
layout if e.g. it is injecting branches to fool the CPU later. There's
a wide range of execution technologies that go under the name JIT and
interpreter, from threaded code to complete compilation to trace based
compilation with bailouts to even more complex schemes. All of them
have Specter issues.

Sincerely,
Watson Ladd

>
> Dave
>
> --
> Bpf mailing list
> Bpf@ietf.org
> https://www.ietf.org/mailman/listinfo/bpf



-- 
Astra mortemque praestare gradatim

Re: [Bpf] BPF ISA Security Considerations section

[Watson Ladd]

On Mon, Apr 22, 2024 at 11:38 AM
<dthaler1968=40googlemail.com@dmarc.ietf.org> 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.
> >
> > Do you have a suggested alternate wording?
>
> 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.

I am very confused about the substance of this recommendation. I've
also got other comments, but will put those in separate reply.

Simply put JITs aren't magic. Whether a bounds check is put in by a
compiler or an interpreter executes it directly, it can still be
speculatively bypassed. If anything JITs may simplify the matter
compared to interpreters as the execution path maps more closely to
the BPF executed, and the BPF will have tighter control of paths and
layout if e.g. it is injecting branches to fool the CPU later. There's
a wide range of execution technologies that go under the name JIT and
interpreter, from threaded code to complete compilation to trace based
compilation with bailouts to even more complex schemes. All of them
have Specter issues.

Sincerely,
Watson Ladd

>
> Dave
>
> --
> Bpf mailing list
> Bpf@ietf.org
> https://www.ietf.org/mailman/listinfo/bpf



-- 
Astra mortemque praestare gradatim

-- 
Bpf mailing list
Bpf@ietf.org
https://www.ietf.org/mailman/listinfo/bpf

Re: BPF ISA Security Considerations section

[David Vernet]

[-- Attachment #1: Type: text/plain, Size: 3738 bytes --]

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.

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

Thanks,
David

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [Bpf] BPF ISA Security Considerations section

[David Vernet]

[-- Attachment #1.1: Type: text/plain, Size: 3738 bytes --]

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.

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

Thanks,
David

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

[-- Attachment #2: Type: text/plain, Size: 76 bytes --]

-- 
Bpf mailing list
Bpf@ietf.org
https://www.ietf.org/mailman/listinfo/bpf

RE: BPF ISA Security Considerations section

[dthaler1968]

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

Re: [Bpf] BPF ISA Security Considerations section

[dthaler1968=40googlemail.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

-- 
Bpf mailing list
Bpf@ietf.org
https://www.ietf.org/mailman/listinfo/bpf

RE: BPF ISA Security Considerations section

[dthaler1968]

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

Re: [Bpf] BPF ISA Security Considerations section

[dthaler1968=40googlemail.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

-- 
Bpf mailing list
Bpf@ietf.org
https://www.ietf.org/mailman/listinfo/bpf

Re: [Bpf] BPF ISA Security Considerations section

[Watson Ladd]

On Mon, Apr 22, 2024 at 1:32 PM
<dthaler1968=40googlemail.com@dmarc.ietf.org> wrote:
>
> > -----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.

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

Sincerely,
Watson
>
> Dave
>
> --
> Bpf mailing list
> Bpf@ietf.org
> https://www.ietf.org/mailman/listinfo/bpf



-- 
Astra mortemque praestare gradatim

Re: [Bpf] BPF ISA Security Considerations section

[Watson Ladd]

On Mon, Apr 22, 2024 at 1:32 PM
<dthaler1968=40googlemail.com@dmarc.ietf.org> wrote:
>
> > -----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.

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

Sincerely,
Watson
>
> Dave
>
> --
> Bpf mailing list
> Bpf@ietf.org
> https://www.ietf.org/mailman/listinfo/bpf



-- 
Astra mortemque praestare gradatim

-- 
Bpf mailing list
Bpf@ietf.org
https://www.ietf.org/mailman/listinfo/bpf

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

[Alan Jowett]

>From: Bpf <bpf-bounces@ietf.org> on behalf of Watson Ladd <watsonbladd@gmail.com>
>Sent: Monday, April 22, 2024 5:19 PM
>To: dthaler1968=40googlemail.com@dmarc.ietf.org <dthaler1968=40googlemail.com@dmarc.ietf.org>
>Cc: dthaler1968@googlemail.com <dthaler1968@googlemail.com>; David Vernet <void@manifault.com>; bpf@ietf.org <bpf@ietf.org>; bpf@vger.kernel.org <bpf@vger.kernel.org>
>Subject: [EXTERNAL] Re: [Bpf] BPF ISA Security Considerations section
>
>On Mon, Apr 22, 2024 at 1:32 PM
><dthaler1968=40googlemail.com@dmarc.ietf.org> wrote:
>>
>> > -----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.
>
>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@ietf.org
>> https://www.ietf.org/mailman/listinfo/bpf
>
>
>
>--
>Astra mortemque praestare gradatim
>
>--
>Bpf mailing list
>Bpf@ietf.org
>https://www.ietf.org/mailman/listinfo/bpf
>

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

[Alan Jowett]

>From: Bpf <bpf-bounces@ietf.org> on behalf of Watson Ladd <watsonbladd@gmail.com>
>Sent: Monday, April 22, 2024 5:19 PM
>To: dthaler1968=40googlemail.com@dmarc.ietf.org <dthaler1968=40googlemail.com@dmarc.ietf.org>
>Cc: dthaler1968@googlemail.com <dthaler1968@googlemail.com>; David Vernet <void@manifault.com>; bpf@ietf.org <bpf@ietf.org>; bpf@vger.kernel.org <bpf@vger.kernel.org>
>Subject: [EXTERNAL] Re: [Bpf] BPF ISA Security Considerations section
>
>On Mon, Apr 22, 2024 at 1:32 PM
><dthaler1968=40googlemail.com@dmarc.ietf.org> wrote:
>>
>> > -----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.
>
>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@ietf.org
>> https://www.ietf.org/mailman/listinfo/bpf
>
>
>
>--
>Astra mortemque praestare gradatim
>
>--
>Bpf mailing list
>Bpf@ietf.org
>https://www.ietf.org/mailman/listinfo/bpf
>
-- 
Bpf mailing list
Bpf@ietf.org
https://www.ietf.org/mailman/listinfo/bpf

RE: [Bpf] BPF ISA Security Considerations section

[dthaler1968]

Thanks Watson and Alan for continued feedback.

Watson wrote:
> But W^X mappings are for JIT (and avoidable by writing, then remapping and
> executing), not interpreters.

Removed W^X phrase.

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

Execution does not require that the interpreter or JIT compiler is in the same
memory space, even if that is the most common implementation.  (And Alan's
point also applies here that compilation might or might not be JIT per se.)

Below is the latest strawman after taking the latest feedback into account...

-Dave


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 and 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. This level of verification can often provide a stronger level
of security assurance than for other software and operating system code.
While the details are out of scope of this document,
`Linux <https://www.kernel.org/doc/html/latest/bpf/verifier.html>`_ and
`PREVAIL <https://pldi19.sigplan.org/details/pldi-2019-papers/44/Simple-and-Precise-Static-Analysis-of-Untrusted-Linux-K                                                                                                               Kernel-Extensions>`_ do provide many details.  Future IETF work will document verifier expectations
and building blocks for allowing safe execution of untrusted BPF programs.

Executing programs using the BPF instruction set also requires either an interpreter or a 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)
whenever one is used in the same memory address space as data with confidentiality
concerns.  As such, use of a compiler is recommended instead.  Compilers should be audited
carefully for vulnerabilities to ensure that compilation of a trusted and verified BPF program
to native processor instructions does not introduce vulnerabilities.

Exposing functionality via BPF extends the interface between the component executing the BPF program and the
component submitting it. Careful consideration of what functionality is exposed and how
that impacts the security properties desired is required.

Re: [Bpf] BPF ISA Security Considerations section

[dthaler1968=40googlemail.com]

Thanks Watson and Alan for continued feedback.

Watson wrote:
> But W^X mappings are for JIT (and avoidable by writing, then remapping and
> executing), not interpreters.

Removed W^X phrase.

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

Execution does not require that the interpreter or JIT compiler is in the same
memory space, even if that is the most common implementation.  (And Alan's
point also applies here that compilation might or might not be JIT per se.)

Below is the latest strawman after taking the latest feedback into account...

-Dave


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 and 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. This level of verification can often provide a stronger level
of security assurance than for other software and operating system code.
While the details are out of scope of this document,
`Linux <https://www.kernel.org/doc/html/latest/bpf/verifier.html>`_ and
`PREVAIL <https://pldi19.sigplan.org/details/pldi-2019-papers/44/Simple-and-Precise-Static-Analysis-of-Untrusted-Linux-K                                                                                                               Kernel-Extensions>`_ do provide many details.  Future IETF work will document verifier expectations
and building blocks for allowing safe execution of untrusted BPF programs.

Executing programs using the BPF instruction set also requires either an interpreter or a 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)
whenever one is used in the same memory address space as data with confidentiality
concerns.  As such, use of a compiler is recommended instead.  Compilers should be audited
carefully for vulnerabilities to ensure that compilation of a trusted and verified BPF program
to native processor instructions does not introduce vulnerabilities.

Exposing functionality via BPF extends the interface between the component executing the BPF program and the
component submitting it. Careful consideration of what functionality is exposed and how
that impacts the security properties desired is required.



-- 
Bpf mailing list
Bpf@ietf.org
https://www.ietf.org/mailman/listinfo/bpf

Re: [Bpf] BPF ISA Security Considerations section

[David Vernet]

[-- Attachment #1: Type: text/plain, Size: 3186 bytes --]

On Tue, Apr 23, 2024 at 10:59:09AM -0700, dthaler1968@googlemail.com wrote:
> Thanks Watson and Alan for continued feedback.
> 
> Watson wrote:
> > But W^X mappings are for JIT (and avoidable by writing, then remapping and
> > executing), not interpreters.
> 
> Removed W^X phrase.
> 
> > 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.
> 
> Execution does not require that the interpreter or JIT compiler is in the same
> memory space, even if that is the most common implementation.  (And Alan's
> point also applies here that compilation might or might not be JIT per se.)
> 
> Below is the latest strawman after taking the latest feedback into account...
> 
> -Dave
> 
> 
> 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 and 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. This level of verification can often provide a stronger level
> of security assurance than for other software and operating system code.
> While the details are out of scope of this document,
> `Linux <https://www.kernel.org/doc/html/latest/bpf/verifier.html>`_ and
> `PREVAIL <https://pldi19.sigplan.org/details/pldi-2019-papers/44/Simple-and-Precise-Static-Analysis-of-Untrusted-Linux-K                                                                                                               Kernel-Extensions>`_ do provide many details.  Future IETF work will document verifier expectations
> and building blocks for allowing safe execution of untrusted BPF programs.
> 
> Executing programs using the BPF instruction set also requires either an interpreter or a 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)
> whenever one is used in the same memory address space as data with confidentiality
> concerns.  As such, use of a compiler is recommended instead.  Compilers should be audited
> carefully for vulnerabilities to ensure that compilation of a trusted and verified BPF program
> to native processor instructions does not introduce vulnerabilities.
> 
> Exposing functionality via BPF extends the interface between the component executing the BPF program and the
> component submitting it. Careful consideration of what functionality is exposed and how
> that impacts the security properties desired is required.

LGTM

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [Bpf] BPF ISA Security Considerations section

[David Vernet]

[-- Attachment #1.1: Type: text/plain, Size: 3186 bytes --]

On Tue, Apr 23, 2024 at 10:59:09AM -0700, dthaler1968@googlemail.com wrote:
> Thanks Watson and Alan for continued feedback.
> 
> Watson wrote:
> > But W^X mappings are for JIT (and avoidable by writing, then remapping and
> > executing), not interpreters.
> 
> Removed W^X phrase.
> 
> > 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.
> 
> Execution does not require that the interpreter or JIT compiler is in the same
> memory space, even if that is the most common implementation.  (And Alan's
> point also applies here that compilation might or might not be JIT per se.)
> 
> Below is the latest strawman after taking the latest feedback into account...
> 
> -Dave
> 
> 
> 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 and 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. This level of verification can often provide a stronger level
> of security assurance than for other software and operating system code.
> While the details are out of scope of this document,
> `Linux <https://www.kernel.org/doc/html/latest/bpf/verifier.html>`_ and
> `PREVAIL <https://pldi19.sigplan.org/details/pldi-2019-papers/44/Simple-and-Precise-Static-Analysis-of-Untrusted-Linux-K                                                                                                               Kernel-Extensions>`_ do provide many details.  Future IETF work will document verifier expectations
> and building blocks for allowing safe execution of untrusted BPF programs.
> 
> Executing programs using the BPF instruction set also requires either an interpreter or a 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)
> whenever one is used in the same memory address space as data with confidentiality
> concerns.  As such, use of a compiler is recommended instead.  Compilers should be audited
> carefully for vulnerabilities to ensure that compilation of a trusted and verified BPF program
> to native processor instructions does not introduce vulnerabilities.
> 
> Exposing functionality via BPF extends the interface between the component executing the BPF program and the
> component submitting it. Careful consideration of what functionality is exposed and how
> that impacts the security properties desired is required.

LGTM

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

[-- Attachment #2: Type: text/plain, Size: 76 bytes --]

-- 
Bpf mailing list
Bpf@ietf.org
https://www.ietf.org/mailman/listinfo/bpf

Re: [Bpf] BPF ISA Security Considerations section

[Watson Ladd]

On Sat, Apr 20, 2024 at 9:09 AM
<dthaler1968=40googlemail.com@dmarc.ietf.org> wrote:
>
> Per https://authors.ietf.org/en/required-content#security-considerations,
> the BPF ISA draft is required to have a Security Considerations section
> before
> it can become an RFC.
>
> Below is strawman text that tries to strike a balance between discussing
> security issues and solutions vs keeping details out of scope that belong in
> other
> documents like the "verifier expectations and building blocks for allowing
> safe
> execution of untrusted BPF programs" document that is a separate item on the
> IETF WG charter.
>
> Proposed text:
>
> > 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.

I would put a reference to the other deliverable to say more. If we
think that's suboptimal for publication strategy, maybe we can be more
generic about it.

Often BPF programs are executed on the other side of a reliability
boundary, e.g. if you execute a BPF filter saying drop all on your
network card, have fun. This isn't different from firewalls and the
like, but it's a new risk that people aren't expecting. I think we
might also need to call out that BPF security assurance requires
careful design and thought about what is exposed via BPF.

Sincerely,
Watson

> Bpf@ietf.org
> https://www.ietf.org/mailman/listinfo/bpf



-- 
Astra mortemque praestare gradatim

Re: [Bpf] BPF ISA Security Considerations section

[Watson Ladd]

On Sat, Apr 20, 2024 at 9:09 AM
<dthaler1968=40googlemail.com@dmarc.ietf.org> wrote:
>
> Per https://authors.ietf.org/en/required-content#security-considerations,
> the BPF ISA draft is required to have a Security Considerations section
> before
> it can become an RFC.
>
> Below is strawman text that tries to strike a balance between discussing
> security issues and solutions vs keeping details out of scope that belong in
> other
> documents like the "verifier expectations and building blocks for allowing
> safe
> execution of untrusted BPF programs" document that is a separate item on the
> IETF WG charter.
>
> Proposed text:
>
> > 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.

I would put a reference to the other deliverable to say more. If we
think that's suboptimal for publication strategy, maybe we can be more
generic about it.

Often BPF programs are executed on the other side of a reliability
boundary, e.g. if you execute a BPF filter saying drop all on your
network card, have fun. This isn't different from firewalls and the
like, but it's a new risk that people aren't expecting. I think we
might also need to call out that BPF security assurance requires
careful design and thought about what is exposed via BPF.

Sincerely,
Watson

> Bpf@ietf.org
> https://www.ietf.org/mailman/listinfo/bpf



-- 
Astra mortemque praestare gradatim

-- 
Bpf mailing list
Bpf@ietf.org
https://www.ietf.org/mailman/listinfo/bpf

RE: [Bpf] BPF ISA Security Considerations section

[dthaler1968]

> -----Original Message-----
> From: Watson Ladd <watsonbladd@gmail.com>
> Sent: Monday, April 22, 2024 12:02 PM
> To: dthaler1968=40googlemail.com@dmarc.ietf.org
> Cc: bpf@ietf.org; bpf@vger.kernel.org
> Subject: Re: [Bpf] BPF ISA Security Considerations section
> 
> On Sat, Apr 20, 2024 at 9:09 AM
> <dthaler1968=40googlemail.com@dmarc.ietf.org> wrote:
> >
> > Per
> > https://authors.ietf.org/en/required-content#security-considerations,
> > the BPF ISA draft is required to have a Security Considerations
> > section before it can become an RFC.
> >
> > Below is strawman text that tries to strike a balance between
> > discussing security issues and solutions vs keeping details out of
> > scope that belong in other documents like the "verifier expectations
> > and building blocks for allowing safe execution of untrusted BPF
> > programs" document that is a separate item on the IETF WG charter.
> >
> > Proposed text:
> >
> > > 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.
> 
> I would put a reference to the other deliverable to say more. If we think that's
> suboptimal for publication strategy, maybe we can be more generic about it.

There's nothing that can be referenced yet.  One can only say it's left for future work,
would you prefer that?

> Often BPF programs are executed on the other side of a reliability boundary, e.g. if
> you execute a BPF filter saying drop all on your network card, have fun. This isn't
> different from firewalls and the like, but it's a new risk that people aren't expecting. I
> think we might also need to call out that BPF security assurance requires careful
> design and thought about what is exposed via BPF.
> 
> Sincerely,
> Watson

Do you have proposed text?

Dave

Re: [Bpf] BPF ISA Security Considerations section

[dthaler1968=40googlemail.com]

> -----Original Message-----
> From: Watson Ladd <watsonbladd@gmail.com>
> Sent: Monday, April 22, 2024 12:02 PM
> To: dthaler1968=40googlemail.com@dmarc.ietf.org
> Cc: bpf@ietf.org; bpf@vger.kernel.org
> Subject: Re: [Bpf] BPF ISA Security Considerations section
> 
> On Sat, Apr 20, 2024 at 9:09 AM
> <dthaler1968=40googlemail.com@dmarc.ietf.org> wrote:
> >
> > Per
> > https://authors.ietf.org/en/required-content#security-considerations,
> > the BPF ISA draft is required to have a Security Considerations
> > section before it can become an RFC.
> >
> > Below is strawman text that tries to strike a balance between
> > discussing security issues and solutions vs keeping details out of
> > scope that belong in other documents like the "verifier expectations
> > and building blocks for allowing safe execution of untrusted BPF
> > programs" document that is a separate item on the IETF WG charter.
> >
> > Proposed text:
> >
> > > 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.
> 
> I would put a reference to the other deliverable to say more. If we think that's
> suboptimal for publication strategy, maybe we can be more generic about it.

There's nothing that can be referenced yet.  One can only say it's left for future work,
would you prefer that?

> Often BPF programs are executed on the other side of a reliability boundary, e.g. if
> you execute a BPF filter saying drop all on your network card, have fun. This isn't
> different from firewalls and the like, but it's a new risk that people aren't expecting. I
> think we might also need to call out that BPF security assurance requires careful
> design and thought about what is exposed via BPF.
> 
> Sincerely,
> Watson

Do you have proposed text?

Dave

-- 
Bpf mailing list
Bpf@ietf.org
https://www.ietf.org/mailman/listinfo/bpf

Re: [Bpf] BPF ISA Security Considerations section

[Watson Ladd]

[-- Attachment #1.1: Type: text/plain, Size: 3602 bytes --]

On Mon, Apr 22, 2024 at 12:06 PM <dthaler1968@googlemail.com> wrote:
>
> > -----Original Message-----
> > From: Watson Ladd <watsonbladd@gmail.com>
> > Sent: Monday, April 22, 2024 12:02 PM
> > To: dthaler1968=40googlemail.com@dmarc.ietf.org
> > Cc: bpf@ietf.org; bpf@vger.kernel.org
> > Subject: Re: [Bpf] BPF ISA Security Considerations section
> >
> > On Sat, Apr 20, 2024 at 9:09 AM
> > <dthaler1968=40googlemail.com@dmarc.ietf.org> wrote:
> > >
> > > Per
> > > https://authors.ietf.org/en/required-content#security-considerations,
> > > the BPF ISA draft is required to have a Security Considerations
> > > section before it can become an RFC.
> > >
> > > Below is strawman text that tries to strike a balance between
> > > discussing security issues and solutions vs keeping details out of
> > > scope that belong in other documents like the "verifier expectations
> > > and building blocks for allowing safe execution of untrusted BPF
> > > programs" document that is a separate item on the IETF WG charter.
> > >
> > > Proposed text:
> > >
> > > > 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.
> >
> > I would put a reference to the other deliverable to say more. If we
think that's
> > suboptimal for publication strategy, maybe we can be more generic about
it.
>
> There's nothing that can be referenced yet.  One can only say it's left
for future work,
> would you prefer that?

I think keeping the existing references while saying "Future work will
address this consideration" is best. Let's give the reader something they
can use.

>
> > Often BPF programs are executed on the other side of a reliability
boundary, e.g. if
> > you execute a BPF filter saying drop all on your network card, have
fun. This isn't
> > different from firewalls and the like, but it's a new risk that people
aren't expecting. I
> > think we might also need to call out that BPF security assurance
requires careful
> > design and thought about what is exposed via BPF.
> >
> > Sincerely,
> > Watson
>
> Do you have proposed text?

"Exposing functionality via BPF extends the interface between the component
executing the BPF and the component submitting it. Careful consideration of
what functionality is supposed to be exposed and how that impacts the
security properties desired is required."

Does this work? Not sure if we have a good example of this causing problems.
>
> Dave
>


-- 
Astra mortemque praestare gradatim

[-- Attachment #1.2: Type: text/html, Size: 5300 bytes --]

[-- Attachment #2: Type: text/plain, Size: 76 bytes --]

-- 
Bpf mailing list
Bpf@ietf.org
https://www.ietf.org/mailman/listinfo/bpf