From: dthaler1968@googlemail.com
To: <dthaler1968@googlemail.com>, "'David Vernet'" <void@manifault.com>
Cc: <bpf@ietf.org>, <bpf@vger.kernel.org>
Subject: RE: BPF ISA Security Considerations section
Date: Mon, 22 Apr 2024 11:37:48 -0700 [thread overview]
Message-ID: <149401da94e4$2da0acd0$88e20670$@gmail.com> (raw)
In-Reply-To: <109c01da9410$331ae880$9950b980$@gmail.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
WARNING: multiple messages have this Message-ID (diff)
From: dthaler1968=40googlemail.com@dmarc.ietf.org
To: <dthaler1968@googlemail.com>, "'David Vernet'" <void@manifault.com>
Cc: <bpf@ietf.org>, <bpf@vger.kernel.org>
Subject: Re: [Bpf] BPF ISA Security Considerations section
Date: Mon, 22 Apr 2024 11:37:48 -0700 [thread overview]
Message-ID: <149401da94e4$2da0acd0$88e20670$@gmail.com> (raw)
Message-ID: <20240422183748.TEdtrGGCTVcTk6EYuWMRW3QnXZ4UGK3r8uD7dkrAiso@z> (raw)
In-Reply-To: <109c01da9410$331ae880$9950b980$@gmail.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
next prev parent reply other threads:[~2024-04-22 18:37 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-20 16:08 BPF ISA Security Considerations section dthaler1968
2024-04-20 16:08 ` [Bpf] " dthaler1968=40googlemail.com
2024-04-21 16:51 ` David Vernet
2024-04-21 16:51 ` [Bpf] " David Vernet
2024-04-21 17:20 ` dthaler1968
2024-04-21 17:20 ` [Bpf] " dthaler1968=40googlemail.com
2024-04-22 18:37 ` dthaler1968 [this message]
2024-04-22 18:37 ` dthaler1968=40googlemail.com
2024-04-22 18:49 ` Watson Ladd
2024-04-22 18:49 ` Watson Ladd
2024-04-22 19:34 ` David Vernet
2024-04-22 19:34 ` [Bpf] " David Vernet
2024-04-22 20:26 ` dthaler1968
2024-04-22 20:26 ` [Bpf] " dthaler1968=40googlemail.com
2024-04-22 20:32 ` dthaler1968
2024-04-22 20:32 ` [Bpf] " dthaler1968=40googlemail.com
2024-04-23 0:19 ` Watson Ladd
2024-04-23 0:19 ` Watson Ladd
2024-04-23 16:00 ` [EXTERNAL] " Alan Jowett
2024-04-23 16:00 ` [Bpf] [EXTERNAL] " Alan Jowett
2024-04-23 17:59 ` [Bpf] " dthaler1968
2024-04-23 17:59 ` dthaler1968=40googlemail.com
2024-04-23 19:59 ` David Vernet
2024-04-23 19:59 ` David Vernet
2024-04-22 19:01 ` Watson Ladd
2024-04-22 19:01 ` Watson Ladd
2024-04-22 19:05 ` dthaler1968
2024-04-22 19:05 ` dthaler1968=40googlemail.com
2024-04-23 1:01 ` Watson Ladd
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='149401da94e4$2da0acd0$88e20670$@gmail.com' \
--to=dthaler1968@googlemail.com \
--cc=bpf@ietf.org \
--cc=bpf@vger.kernel.org \
--cc=void@manifault.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.