Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.33 as permitted sender) client-ip=23.128.96.33;
MIME-Version: 1.0
References: <20231009124046.74710-1-hengqi.chen@gmail.com> <20231009124046.74710-3-hengqi.chen@gmail.com>
 <202310101722.B6D6E6CEC@keescook>
In-Reply-To: <202310101722.B6D6E6CEC@keescook>
From:   Hengqi Chen <hengqi.chen@gmail.com>
Date:   Thu, 12 Oct 2023 09:48:22 +0800
Message-ID: <CAEyhmHSufv0hH_xY7SBfyc+GrG5ao-cUvjRZotV1neS7f6NGxQ@mail.gmail.com>
Subject: Re: [PATCH 2/4] seccomp, bpf: Introduce SECCOMP_LOAD_FILTER operation
To:     Kees Cook <keescook@chromium.org>
Cc:     linux-kernel@vger.kernel.org, bpf@vger.kernel.org, ast@kernel.org,
        daniel@iogearbox.net, andrii@kernel.org, luto@amacapital.net,
        wad@chromium.org, alexyonghe@tencent.com
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Wed, Oct 11, 2023 at 8:24=E2=80=AFAM Kees Cook <keescook@chromium.org> w=
rote:
>
> On Mon, Oct 09, 2023 at 12:40:44PM +0000, Hengqi Chen wrote:
> > This patch adds a new operation named SECCOMP_LOAD_FILTER.
> > It accepts the same arguments as SECCOMP_SET_MODE_FILTER
> > but only performs the loading process. If succeed, return a
> > new fd associated with the JITed BPF program (the filter).
> > The filter can then be pinned to bpffs using the returned
> > fd and reused for different processes. To distinguish the
> > filter from other BPF progs, BPF_PROG_TYPE_SECCOMP is added.
> >
> > Signed-off-by: Hengqi Chen <hengqi.chen@gmail.com>
>
> This part looks okay, I think. I need to spend some more time looking at
> the BPF side. I want to make sure it is only possible to build a
> BPF_PROG_TYPE_SECCOMP prog by going through seccomp. I want to make sure
> we can never side-load some kind of unexpected program into seccomp,
> etc. Since BPF_PROG_TYPE_SECCOMP is part of UAPI, is this controllable
> through the bpf() syscall?
>

Currently, it failed at find_prog_type() since we don't register the
prog type to BPF.

> One thought I had, though, is I wonder if flags are needed to be
> included with the fd? I'll ponder this a bit more...
>

bpf_prog_new_fd() already set O_RDWR and O_CLOEXEC.

> --
> Kees Cook