All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kees Cook <keescook@chromium.org>
To: Hengqi Chen <hengqi.chen@gmail.com>
Cc: linux-kernel@vger.kernel.org, bpf@vger.kernel.org,
	luto@amacapital.net, wad@chromium.org, alexyonghe@tencent.com
Subject: Re: [RFC PATCH 0/2] seccomp: Split set filter into two steps
Date: Tue, 3 Oct 2023 11:01:52 -0700	[thread overview]
Message-ID: <202310031055.3F19F87@keescook> (raw)
In-Reply-To: <20231003083836.100706-1-hengqi.chen@gmail.com>

On Tue, Oct 03, 2023 at 08:38:34AM +0000, Hengqi Chen wrote:
> This patchset introduces two new operations which essentially
> splits the SECCOMP_SET_MODE_FILTER process into two steps:
> SECCOMP_LOAD_FILTER and SECCOMP_ATTACH_FILTER.
> 
> The SECCOMP_LOAD_FILTER loads the filter and returns a fd
> which can be pinned to bpffs. This extends the lifetime of the
> filter and thus can be reused by different processes.
> With this new operation, we can eliminate a hot path of JITing
> BPF program (the filter) where we apply the same seccomp filter
> to thousands of micro VMs on a bare metal instance.
> 
> The SECCOMP_ATTACH_FILTER is used to attach a loaded filter.
> The filter is represented by a fd which is either returned
> from SECCOMP_LOAD_FILTER or obtained from bpffs using bpf syscall.

Interesting! I like this idea, thanks for writing it up.

Two design notes:

- Can you reuse/refactor seccomp_prepare_filter() instead of duplicating
  the logic into two new functions?

- Is there a way to make sure the BPF program coming from the fd is one
  that was built via SECCOMP_LOAD_FILTER? (I want to make sure we can
  never confuse a non-seccomp program into getting loaded into seccomp.)

-Kees

-- 
Kees Cook

  parent reply	other threads:[~2023-10-03 18:01 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-03  8:38 [RFC PATCH 0/2] seccomp: Split set filter into two steps Hengqi Chen
2023-10-03  8:38 ` [RFC PATCH 1/2] seccomp: Introduce SECCOMP_LOAD_FILTER operation Hengqi Chen
2023-10-03 16:17   ` kernel test robot
2023-10-03 16:28   ` kernel test robot
2023-10-03  8:38 ` [RFC PATCH 2/2] seccomp: Introduce SECCOMP_ATTACH_FILTER operation Hengqi Chen
2023-10-03 20:28   ` kernel test robot
2023-10-03 18:01 ` Kees Cook [this message]
2023-10-06  7:58   ` [RFC PATCH 0/2] seccomp: Split set filter into two steps Hengqi Chen
2023-10-04 14:03 ` Rodrigo Campos
2023-10-06  8:12   ` Hengqi Chen

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=202310031055.3F19F87@keescook \
    --to=keescook@chromium.org \
    --cc=alexyonghe@tencent.com \
    --cc=bpf@vger.kernel.org \
    --cc=hengqi.chen@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@amacapital.net \
    --cc=wad@chromium.org \
    /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.