public inbox for linux-kselftest@vger.kernel.org
 help / color / mirror / Atom feed
From: Roberto Sassu <roberto.sassu@huawei.com>
To: "dhowells@redhat.com" <dhowells@redhat.com>
Cc: "ast@kernel.org" <ast@kernel.org>,
	"andrii@kernel.org" <andrii@kernel.org>,
	"john.fastabend@gmail.com" <john.fastabend@gmail.com>,
	"songliubraving@fb.com" <songliubraving@fb.com>,
	"kafai@fb.com" <kafai@fb.com>, "yhs@fb.com" <yhs@fb.com>,
	"keyrings@vger.kernel.org" <keyrings@vger.kernel.org>,
	"bpf@vger.kernel.org" <bpf@vger.kernel.org>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"linux-kselftest@vger.kernel.org"
	<linux-kselftest@vger.kernel.org>,
	"linux-security-module@vger.kernel.org" 
	<linux-security-module@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	KP Singh <kpsingh@kernel.org>,
	"Daniel Borkmann" <daniel@iogearbox.net>
Subject: RE: [PATCH v6 4/5] bpf: Add bpf_verify_pkcs7_signature() helper
Date: Fri, 8 Jul 2022 12:12:25 +0000	[thread overview]
Message-ID: <2be48d62b0c141799f0c54cbe63f6dc3@huawei.com> (raw)
In-Reply-To: <52aa81c8037640a7935cdfd6f363a07d@huawei.com>

> From: Roberto Sassu [mailto:roberto.sassu@huawei.com]
> Sent: Thursday, July 7, 2022 1:01 PM
> > From: KP Singh [mailto:kpsingh@kernel.org]
> > Sent: Thursday, July 7, 2022 1:49 AM
> > On Wed, Jul 6, 2022 at 6:04 PM Daniel Borkmann <daniel@iogearbox.net>
> > wrote:

[...]

> > > nit: when both trusted_keyring_serial and trusted_keyring_id are passed to
> the
> > > helper, then this should be rejected as invalid argument? (Kind of feels a bit
> > > like we're cramming two things in one helper.. KP, thoughts? :))
> >
> > EINVAL when both are passed seems reasonable. The signature (pun?) of the
> > does seem to get bloated, but I am not sure if it's worth adding two
> > helpers here.
> 
> Ok for EINVAL. Should I change the trusted_keyring_id type to signed,
> and use -1 when it should not be specified?

I still have the impression that a helper for lookup_user_key() is the
preferred solution, despite the access control concern.

David, may ask if this is the correct way to use the key subsystem
API when permission check is deferred? key_permission() is currently
not defined outside the key subsystem.

The first three functions will be exposed by the kernel to eBPF programs
and can be called at any time. bpf_<key_helper> is a generic helper
dealing with a key.

BPF_CALL_2(bpf_lookup_user_key, u32, serial, unsigned long, flags)
{
...
        key_ref = lookup_user_key(serial, flags, KEY_DEFER_PERM_CHECK);
...
        return (unsigned long)key_ref_to_ptr(key_ref);
}

BPF_CALL_X(bpf_<key_helper>, struct key, *key, ...)
{
        ret = key_read_state(key);
...
        ret = key_validate(key);
...
        ret = key_permission(key_ref, <key helper-specific permission>);
...
}

BPF_CALL_1(bpf_key_put, struct key *, key)
{
        key_put(key);
        return 0;
}

An eBPF program would do for example:

SEC("lsm.s/bpf")
int BPF_PROG(bpf, int cmd, union bpf_attr *attr, unsigned int size)
{
        struct key *key;
...
        key = bpf_lookup_user_key(serial, flags);
...
        ret = bpf_key_helper(key, ...);
...
        key_put(key);
}

Thanks

Roberto

  reply	other threads:[~2022-07-08 12:12 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-28 12:27 [PATCH v6 0/5] bpf: Add bpf_verify_pkcs7_signature() helper Roberto Sassu
2022-06-28 12:27 ` [PATCH v6 1/5] bpf: Export bpf_dynptr_get_size() Roberto Sassu
2022-06-28 12:27 ` [PATCH v6 2/5] KEYS: Move KEY_LOOKUP_ to include/linux/key.h Roberto Sassu
2022-06-28 12:27 ` [PATCH v6 3/5] scripts: Handle unsigned type prefix in bpf_doc.py Roberto Sassu
2022-06-28 12:27 ` [PATCH v6 4/5] bpf: Add bpf_verify_pkcs7_signature() helper Roberto Sassu
2022-07-06 16:03   ` Daniel Borkmann
2022-07-06 23:49     ` KP Singh
2022-07-07 11:00       ` Roberto Sassu
2022-07-08 12:12         ` Roberto Sassu [this message]
2022-06-28 12:27 ` [PATCH v6 5/5] selftests/bpf: Add test for " Roberto Sassu
2022-06-28 12:32   ` Roberto Sassu

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=2be48d62b0c141799f0c54cbe63f6dc3@huawei.com \
    --to=roberto.sassu@huawei.com \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=dhowells@redhat.com \
    --cc=john.fastabend@gmail.com \
    --cc=kafai@fb.com \
    --cc=keyrings@vger.kernel.org \
    --cc=kpsingh@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=songliubraving@fb.com \
    --cc=yhs@fb.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox