From: Rodrigo Campos <rodrigo@sdfg.com.ar>
To: Hengqi Chen <hengqi.chen@gmail.com>,
linux-kernel@vger.kernel.org, bpf@vger.kernel.org
Cc: keescook@chromium.org, luto@amacapital.net, wad@chromium.org,
alexyonghe@tencent.com,
Alban Crequy <albancrequy@linux.microsoft.com>
Subject: Re: [RFC PATCH 0/2] seccomp: Split set filter into two steps
Date: Wed, 4 Oct 2023 16:03:24 +0200 [thread overview]
Message-ID: <14c52402-ebc8-4425-9871-1663a87182ef@sdfg.com.ar> (raw)
In-Reply-To: <20231003083836.100706-1-hengqi.chen@gmail.com>
On 10/3/23 10:38, 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.
A quick question to see if handling something else too is
possible/reasonable to do here too.
Let me explain our use case first.
For us (Alban in cc) it would be great if we can extend the lifetime of
the fd returned, so the process managing a seccomp notification in
userspace can easly crash or be updated. Today, if the agent that got
the fd crashes, all the "notify-syscalls" return ENOSYS in the target
process.
Our use case is we created a seccomp agent to use in Kubernetes
(github.com/kinvolk/seccompagent) and we need to handle either the agent
crashing or upgrading it. We were thinking tricks to have another
container that just stores fds and make sure that never crashes, but it
is not ideal (we checked tricks to use systemd to store our fds, but it
is not simpler either to use from containers).
If the agent crashes today, all the syscalls return ENOSYS. It will be
great if we can make the process doing the syscall just wait until a new
process to handle the notifications is up and the syscalls done in the
meantime are just queued. A mode of saying "if the agent crashes, just
queue notifications, one agent to pick them up will come back soon" (we
can of course limit reasonably the notification queue).
It seems the split here would not just work for that use case. I think
we would need to pin the attachment.
Do you think handling that is something reasonable to do in this series too?
I'll be afk until end next week. I'll catch up as soon as I'm back with
internet :)
Best,
Rodrigo
next prev parent reply other threads:[~2023-10-04 14:03 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 ` [RFC PATCH 0/2] seccomp: Split set filter into two steps Kees Cook
2023-10-06 7:58 ` Hengqi Chen
2023-10-04 14:03 ` Rodrigo Campos [this message]
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=14c52402-ebc8-4425-9871-1663a87182ef@sdfg.com.ar \
--to=rodrigo@sdfg.com.ar \
--cc=albancrequy@linux.microsoft.com \
--cc=alexyonghe@tencent.com \
--cc=bpf@vger.kernel.org \
--cc=hengqi.chen@gmail.com \
--cc=keescook@chromium.org \
--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.