Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.32 as permitted sender) client-ip=23.128.96.32;
MIME-Version: 1.0
References: <20231003083836.100706-1-hengqi.chen@gmail.com> <14c52402-ebc8-4425-9871-1663a87182ef@sdfg.com.ar>
In-Reply-To: <14c52402-ebc8-4425-9871-1663a87182ef@sdfg.com.ar>
From:   Hengqi Chen <hengqi.chen@gmail.com>
Date:   Fri, 6 Oct 2023 16:12:29 +0800
Message-ID: <CAEyhmHSJga3NMtZDy4CzM6fQcc5-LVGouprd7N8Gd8EH2Nqpqg@mail.gmail.com>
Subject: Re: [RFC PATCH 0/2] seccomp: Split set filter into two steps
To:     Rodrigo Campos <rodrigo@sdfg.com.ar>
Cc:     linux-kernel@vger.kernel.org, bpf@vger.kernel.org,
        keescook@chromium.org, luto@amacapital.net, wad@chromium.org,
        alexyonghe@tencent.com,
        Alban Crequy <albancrequy@linux.microsoft.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Wed, Oct 4, 2023 at 10:03=E2=80=AFPM Rodrigo Campos <rodrigo@sdfg.com.ar=
> wrote:
>
> 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 t=
oo?
>

I am not familiar with this notification mechanism, but it seems unrelated.
This patchset is trying to reuse the seccomp filter itself.

> I'll be afk until end next week. I'll catch up as soon as I'm back with
> internet :)
>
>
>
> Best,
> Rodrigo

--
Hengqi