From: John Fastabend <john.fastabend@gmail.com>
To: Roberto Sassu <roberto.sassu@huawei.com>,
ast@kernel.org, daniel@iogearbox.net, andrii@kernel.org,
kpsingh@kernel.org, john.fastabend@gmail.com,
songliubraving@fb.com, kafai@fb.com, yhs@fb.com
Cc: dhowells@redhat.com, keyrings@vger.kernel.org,
bpf@vger.kernel.org, netdev@vger.kernel.org,
linux-kselftest@vger.kernel.org, linux-kernel@vger.kernel.org,
Roberto Sassu <roberto.sassu@huawei.com>,
kernel test robot <lkp@intel.com>
Subject: RE: [PATCH v5 3/5] bpf: Add bpf_verify_pkcs7_signature() helper
Date: Tue, 21 Jun 2022 15:27:46 -0700 [thread overview]
Message-ID: <62b245e22effa_1627420871@john.notmuch> (raw)
In-Reply-To: <20220621163757.760304-4-roberto.sassu@huawei.com>
Roberto Sassu wrote:
> Add the bpf_verify_pkcs7_signature() helper, to give eBPF security modules
> the ability to check the validity of a signature against supplied data, by
> using user-provided or system-provided keys as trust anchor.
>
> The new helper makes it possible to enforce mandatory policies, as eBPF
> programs might be allowed to make security decisions only based on data
> sources the system administrator approves.
>
> The caller should provide both the data to be verified and the signature as
> eBPF dynamic pointers (to minimize the number of parameters).
>
> The caller should also provide a keyring pointer obtained with
> bpf_lookup_user_key() or, alternatively, a keyring ID with values defined
> in verification.h. While the first choice gives users more flexibility, the
> second offers better security guarantees, as the keyring selection will not
> depend on possibly untrusted user space but on the kernel itself.
>
> Defined keyring IDs are: 0 for the primary keyring (immutable keyring of
> system keys); 1 for both the primary and secondary keyring (where keys can
> be added only if they are vouched for by existing keys in those keyrings);
> 2 for the platform keyring (primarily used by the integrity subsystem to
> verify a kexec'ed kerned image and, possibly, the initramfs signature).
>
> Note: since the keyring ID assignment is understood only by
> verify_pkcs7_signature(), it must be passed directly to the corresponding
> helper, rather than to a separate new helper returning a struct key pointer
> with the keyring ID as a pointer value. If such pointer is passed to any
> other helper which does not check its validity, an illegal memory access
> could occur.
>
> Signed-off-by: Roberto Sassu <roberto.sassu@huawei.com>
> Reported-by: kernel test robot <lkp@intel.com> (cast warning)
> ---
> include/uapi/linux/bpf.h | 17 +++++++++++++++
> kernel/bpf/bpf_lsm.c | 39 ++++++++++++++++++++++++++++++++++
> tools/include/uapi/linux/bpf.h | 17 +++++++++++++++
> 3 files changed, 73 insertions(+)
>
> diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
> index 7bbcf2cd105d..524bed4d7170 100644
> --- a/include/uapi/linux/bpf.h
> +++ b/include/uapi/linux/bpf.h
> @@ -5339,6 +5339,22 @@ union bpf_attr {
> * bpf_lookup_user_key() helper.
> * Return
> * 0
> + *
> + * long bpf_verify_pkcs7_signature(struct bpf_dynptr *data_ptr, struct bpf_dynptr *sig_ptr, struct key *trusted_keys, unsigned long keyring_id)
> + * Description
> + * Verify the PKCS#7 signature *sig* against the supplied *data*
> + * with keys in *trusted_keys* or in a keyring with ID
> + * *keyring_id*.
Would be nice to give precedence here so that its obvious order between
trusted_keys and keyring_id.
> + *
> + * *keyring_id* can have the following values defined in
> + * verification.h: 0 for the primary keyring (immutable keyring of
> + * system keys); 1 for both the primary and secondary keyring
> + * (where keys can be added only if they are vouched for by
> + * existing keys in those keyrings); 2 for the platform keyring
> + * (primarily used by the integrity subsystem to verify a kexec'ed
> + * kerned image and, possibly, the initramfs signature).
> + * Return
> + * 0 on success, a negative value on error.
> */
next prev parent reply other threads:[~2022-06-21 22:27 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-21 16:37 [PATCH v5 0/5] bpf: Add bpf_verify_pkcs7_signature() helper Roberto Sassu
2022-06-21 16:37 ` [PATCH v5 1/5] bpf: Export bpf_dynptr_get_size() Roberto Sassu
2022-06-21 16:37 ` [PATCH v5 2/5] bpf: Add bpf_lookup_user_key() and bpf_key_put() helpers Roberto Sassu
2022-06-21 22:32 ` Alexei Starovoitov
2022-06-22 7:12 ` Roberto Sassu
2022-06-23 12:36 ` Roberto Sassu
2022-06-23 20:54 ` Alexei Starovoitov
2022-06-24 15:32 ` Roberto Sassu
2022-06-24 16:50 ` Alexei Starovoitov
2022-06-24 17:38 ` Roberto Sassu
2022-06-24 15:59 ` Roberto Sassu
2022-06-21 16:37 ` [PATCH v5 3/5] bpf: Add bpf_verify_pkcs7_signature() helper Roberto Sassu
2022-06-21 22:27 ` John Fastabend [this message]
2022-06-22 9:54 ` Roberto Sassu
2022-06-23 1:27 ` John Fastabend
2022-06-21 16:37 ` [PATCH v5 4/5] selftests/bpf: Add test for unreleased key references Roberto Sassu
2022-06-21 22:35 ` John Fastabend
2022-06-22 7:14 ` Roberto Sassu
2022-06-21 16:37 ` [PATCH v5 5/5] selftests/bpf: Add test for bpf_verify_pkcs7_signature() helper Roberto Sassu
2022-06-21 22:31 ` Alexei Starovoitov
2022-06-22 7:06 ` Roberto Sassu
2022-06-22 18:16 ` Alexei Starovoitov
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=62b245e22effa_1627420871@john.notmuch \
--to=john.fastabend@gmail.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=dhowells@redhat.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=lkp@intel.com \
--cc=netdev@vger.kernel.org \
--cc=roberto.sassu@huawei.com \
--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 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.