All of lore.kernel.org
 help / color / mirror / Atom feed
From: Blaise Boscaccy <bboscaccy@linux.microsoft.com>
To: Paul Moore <paul@paul-moore.com>, Song Liu <song@kernel.org>
Cc: James Morris <jmorris@namei.org>,
	"Serge E. Hallyn" <serge@hallyn.com>,
	Alexei Starovoitov <ast@kernel.org>,
	Daniel Borkmann <daniel@iogearbox.net>,
	John Fastabend <john.fastabend@gmail.com>,
	Andrii Nakryiko <andrii@kernel.org>,
	Martin KaFai Lau <martin.lau@linux.dev>,
	Eduard Zingerman <eddyz87@gmail.com>,
	Yonghong Song <yonghong.song@linux.dev>,
	KP Singh <kpsingh@kernel.org>,
	Stanislav Fomichev <sdf@fomichev.me>, Hao Luo <haoluo@google.com>,
	Jiri Olsa <jolsa@kernel.org>,
	Stephen Smalley <stephen.smalley.work@gmail.com>,
	Ondrej Mosnacek <omosnace@redhat.com>,
	linux-security-module@vger.kernel.org,
	linux-kernel@vger.kernel.org, bpf@vger.kernel.org,
	selinux@vger.kernel.org
Subject: Re: [PATCH 1/1] security: Propagate universal pointer data in bpf hooks
Date: Wed, 26 Feb 2025 11:40:08 -0800	[thread overview]
Message-ID: <87mse8jy07.fsf@microsoft.com> (raw)
In-Reply-To: <CAHC9VhS8ST6ODB2pFJTMK4qu8FdM2J=6qEbB=XGxo2ZAZgo1Aw@mail.gmail.com>

Paul Moore <paul@paul-moore.com> writes:

> On Wed, Feb 26, 2025 at 2:06 AM Song Liu <song@kernel.org> wrote:
>> On Tue, Feb 25, 2025 at 4:31 PM Blaise Boscaccy
>> <bboscaccy@linux.microsoft.com> wrote:
>> >
>> > Certain bpf syscall subcommands are available for usage from both
>> > userspace and the kernel. LSM modules or eBPF gatekeeper programs may
>> > need to take a different course of action depending on whether or not
>> > a BPF syscall originated from the kernel or userspace.
>> >
>> > Additionally, some of the bpf_attr struct fields contain pointers to
>> > arbitrary memory. Currently the functionality to determine whether or
>> > not a pointer refers to kernel memory or userspace memory is exposed
>> > to the bpf verifier, but that information is missing from various LSM
>> > hooks.
>> >
>> > Here we augment the LSM hooks to provide this data, by simply passing
>> > the corresponding universal pointer in any hook that contains already
>> > contains a bpf_attr struct that corresponds to a subcommand that may
>> > be called from the kernel.
>>
>> I think this information is useful for LSM hooks.
>
> I've only looked at it quickly, but so far it seems reasonable.  I'm
> going to take a closer look today.
>
>> Question: Do we need a full bpfptr_t for these hooks, or just a boolean
>> "is_kernel or not"?
>
> I may be misunderstanding the patch, but what if we swapped the
> existing 'union bpf_attr' parameter for a 'bpfptr_t' parameter?  That
> would allow for both kernel and usermode pointers, complete with a
> 'is_kernel' flag; or am I missing something (likely)?
>
> -- 
> paul-moore.com

bpfptr_t is just a typedef for a sockptr_t, which contains a void
pointer and bool, so if we replaced bpf_attr with it, we might lose a
bit of type safety going that route.

In syscall.c a most of the subcommand handlers have a

static int bpf_foo(union bpf_attr *attr, bpfptr_t uattr);

pattern that is used. I was trying to mimic for this patch.

The actual parts where the is_kernel flag gets used currently, is for
pointer chasing/copy stuff, e.g.

make_bpfptr(attr->insns, uattr.is_kernel)
make_bpfptr(attr->license, uattr.is_kernel)
make_bpfptr(attr->fd_array, uattr.is_kernel)

and subcommand structs may contain multiple pointers.

-blaise

  reply	other threads:[~2025-02-26 19:40 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-02-26  0:30 [PATCH 0/1] security: Propagate universal pointer data in bpf hooks Blaise Boscaccy
2025-02-26  0:30 ` [PATCH 1/1] " Blaise Boscaccy
2025-02-26  7:06   ` Song Liu
2025-02-26 15:57     ` Paul Moore
2025-02-26 19:40       ` Blaise Boscaccy [this message]
2025-02-26 16:00     ` Alexei Starovoitov
2025-02-26 19:21       ` Blaise Boscaccy
2025-02-26 22:02       ` Song Liu

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=87mse8jy07.fsf@microsoft.com \
    --to=bboscaccy@linux.microsoft.com \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=eddyz87@gmail.com \
    --cc=haoluo@google.com \
    --cc=jmorris@namei.org \
    --cc=john.fastabend@gmail.com \
    --cc=jolsa@kernel.org \
    --cc=kpsingh@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=martin.lau@linux.dev \
    --cc=omosnace@redhat.com \
    --cc=paul@paul-moore.com \
    --cc=sdf@fomichev.me \
    --cc=selinux@vger.kernel.org \
    --cc=serge@hallyn.com \
    --cc=song@kernel.org \
    --cc=stephen.smalley.work@gmail.com \
    --cc=yonghong.song@linux.dev \
    /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.