2023-11-19 00:32:49

by Vadim Fedorenko

[permalink] [raw]
Subject: [PATCH bpf-next v5 1/2] bpf: add skcipher API support to TC/XDP programs

Add crypto API support to BPF to be able to decrypt or encrypt packets
in TC/XDP BPF programs. Only symmetric key ciphers are supported for
now. Special care should be taken for initialization part of crypto algo
because crypto_alloc_sync_skcipher() doesn't work with preemtion
disabled, it can be run only in sleepable BPF program. Also async crypto
is not supported because of the very same issue - TC/XDP BPF programs
are not sleepable.

Signed-off-by: Vadim Fedorenko <[email protected]>
---
v4 -> v5:
- replace crypto API to use lskcipher (suggested by Herbert Xu)
- remove SG list usage and provide raw buffers
v3 -> v4:
- reuse __bpf_dynptr_data and remove own implementation
- use const __str to provide algorithm name
- use kfunc macroses to avoid compilator warnings
v2 -> v3:
- fix kdoc issues
v1 -> v2:
- use kmalloc in sleepable func, suggested by Alexei
- use __bpf_dynptr_is_rdonly() to check destination, suggested by Jakub
- use __bpf_dynptr_data_ptr() for all dynptr accesses
---
include/linux/bpf.h | 1 +
kernel/bpf/Makefile | 3 +
kernel/bpf/crypto.c | 258 ++++++++++++++++++++++++++++++++++++++++++
kernel/bpf/helpers.c | 2 +-
kernel/bpf/verifier.c | 1 +
5 files changed, 264 insertions(+), 1 deletion(-)
create mode 100644 kernel/bpf/crypto.c

diff --git a/include/linux/bpf.h b/include/linux/bpf.h
index 4001d11be151..77934ab7421d 100644
--- a/include/linux/bpf.h
+++ b/include/linux/bpf.h
@@ -1224,6 +1224,7 @@ int bpf_dynptr_check_size(u32 size);
u32 __bpf_dynptr_size(const struct bpf_dynptr_kern *ptr);
const void *__bpf_dynptr_data(const struct bpf_dynptr_kern *ptr, u32 len);
void *__bpf_dynptr_data_rw(const struct bpf_dynptr_kern *ptr, u32 len);
+bool __bpf_dynptr_is_rdonly(const struct bpf_dynptr_kern *ptr);

#ifdef CONFIG_BPF_JIT
int bpf_trampoline_link_prog(struct bpf_tramp_link *link, struct bpf_trampoline *tr);
diff --git a/kernel/bpf/Makefile b/kernel/bpf/Makefile
index f526b7573e97..e14b5834c477 100644
--- a/kernel/bpf/Makefile
+++ b/kernel/bpf/Makefile
@@ -41,6 +41,9 @@ obj-$(CONFIG_BPF_SYSCALL) += bpf_struct_ops.o
obj-$(CONFIG_BPF_SYSCALL) += cpumask.o
obj-${CONFIG_BPF_LSM} += bpf_lsm.o
endif
+ifeq ($(CONFIG_CRYPTO_SKCIPHER),y)
+obj-$(CONFIG_BPF_SYSCALL) += crypto.o
+endif
obj-$(CONFIG_BPF_PRELOAD) += preload/

obj-$(CONFIG_BPF_SYSCALL) += relo_core.o
diff --git a/kernel/bpf/crypto.c b/kernel/bpf/crypto.c
new file mode 100644
index 000000000000..20ef9aadaba8
--- /dev/null
+++ b/kernel/bpf/crypto.c
@@ -0,0 +1,258 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/* Copyright (c) 2023 Meta, Inc */
+#include <linux/bpf.h>
+#include <linux/bpf_mem_alloc.h>
+#include <linux/btf.h>
+#include <linux/btf_ids.h>
+#include <linux/filter.h>
+#include <linux/scatterlist.h>
+#include <linux/skbuff.h>
+#include <crypto/skcipher.h>
+
+/**
+ * struct bpf_crypto_lskcipher_ctx - refcounted BPF sync skcipher context structure
+ * @tfm: The pointer to crypto_sync_skcipher struct.
+ * @rcu: The RCU head used to free the crypto context with RCU safety.
+ * @usage: Object reference counter. When the refcount goes to 0, the
+ * memory is released back to the BPF allocator, which provides
+ * RCU safety.
+ */
+struct bpf_crypto_lskcipher_ctx {
+ struct crypto_lskcipher *tfm;
+ struct rcu_head rcu;
+ refcount_t usage;
+};
+
+__bpf_kfunc_start_defs();
+
+/**
+ * bpf_crypto_lskcipher_ctx_create() - Create a mutable BPF crypto context.
+ *
+ * Allocates a crypto context that can be used, acquired, and released by
+ * a BPF program. The crypto context returned by this function must either
+ * be embedded in a map as a kptr, or freed with bpf_crypto_skcipher_ctx_release().
+ * As crypto API functions use GFP_KERNEL allocations, this function can
+ * only be used in sleepable BPF programs.
+ *
+ * bpf_crypto_lskcipher_ctx_create() allocates memory for crypto context.
+ * It may return NULL if no memory is available.
+ * @algo__str: pointer to string representation of algorithm.
+ * @pkey: bpf_dynptr which holds cipher key to do crypto.
+ * @err: integer to store error code when NULL is returned
+ */
+__bpf_kfunc struct bpf_crypto_lskcipher_ctx *
+bpf_crypto_lskcipher_ctx_create(const char *algo__str, const struct bpf_dynptr_kern *pkey,
+ int *err)
+{
+ struct bpf_crypto_lskcipher_ctx *ctx;
+ const u8 *key;
+ u32 key_len;
+
+ if (!crypto_has_skcipher(algo__str, CRYPTO_ALG_TYPE_SKCIPHER, CRYPTO_ALG_TYPE_MASK)) {
+ *err = -EOPNOTSUPP;
+ return NULL;
+ }
+
+ key_len = __bpf_dynptr_size(pkey);
+ if (!key_len) {
+ *err = -EINVAL;
+ return NULL;
+ }
+ key = __bpf_dynptr_data(pkey, key_len);
+ if (!key) {
+ *err = -EINVAL;
+ return NULL;
+ }
+
+ ctx = kzalloc(sizeof(*ctx), GFP_KERNEL);
+ if (!ctx) {
+ *err = -ENOMEM;
+ return NULL;
+ }
+
+ ctx->tfm = crypto_alloc_lskcipher(algo__str, 0, 0);
+ if (IS_ERR(ctx->tfm)) {
+ *err = PTR_ERR(ctx->tfm);
+ ctx->tfm = NULL;
+ goto err;
+ }
+
+ *err = crypto_lskcipher_setkey(ctx->tfm, key, key_len);
+ if (*err)
+ goto err;
+
+ refcount_set(&ctx->usage, 1);
+
+ return ctx;
+err:
+ if (ctx->tfm)
+ crypto_free_lskcipher(ctx->tfm);
+ kfree(ctx);
+
+ return NULL;
+}
+
+static void crypto_free_lskcipher_cb(struct rcu_head *head)
+{
+ struct bpf_crypto_lskcipher_ctx *ctx;
+
+ ctx = container_of(head, struct bpf_crypto_lskcipher_ctx, rcu);
+ crypto_free_lskcipher(ctx->tfm);
+ kfree(ctx);
+}
+
+/**
+ * bpf_crypto_lskcipher_ctx_acquire() - Acquire a reference to a BPF crypto context.
+ * @ctx: The BPF crypto context being acquired. The ctx must be a trusted
+ * pointer.
+ *
+ * Acquires a reference to a BPF crypto context. The context returned by this function
+ * must either be embedded in a map as a kptr, or freed with
+ * bpf_crypto_skcipher_ctx_release().
+ */
+__bpf_kfunc struct bpf_crypto_lskcipher_ctx *
+bpf_crypto_lskcipher_ctx_acquire(struct bpf_crypto_lskcipher_ctx *ctx)
+{
+ refcount_inc(&ctx->usage);
+ return ctx;
+}
+
+/**
+ * bpf_crypto_lskcipher_ctx_release() - Release a previously acquired BPF crypto context.
+ * @ctx: The crypto context being released.
+ *
+ * Releases a previously acquired reference to a BPF cpumask. When the final
+ * reference of the BPF cpumask has been released, it is subsequently freed in
+ * an RCU callback in the BPF memory allocator.
+ */
+__bpf_kfunc void bpf_crypto_lskcipher_ctx_release(struct bpf_crypto_lskcipher_ctx *ctx)
+{
+ if (refcount_dec_and_test(&ctx->usage))
+ call_rcu(&ctx->rcu, crypto_free_lskcipher_cb);
+}
+
+static int bpf_crypto_lskcipher_crypt(struct crypto_lskcipher *tfm,
+ const struct bpf_dynptr_kern *src,
+ struct bpf_dynptr_kern *dst,
+ const struct bpf_dynptr_kern *iv,
+ bool decrypt)
+{
+ u32 src_len, dst_len, iv_len;
+ const u8 *psrc;
+ u8 *pdst, *piv;
+ int err;
+
+ if (crypto_lskcipher_get_flags(tfm) & CRYPTO_TFM_NEED_KEY)
+ return -EINVAL;
+
+ if (__bpf_dynptr_is_rdonly(dst))
+ return -EINVAL;
+
+ iv_len = __bpf_dynptr_size(iv);
+ src_len = __bpf_dynptr_size(src);
+ dst_len = __bpf_dynptr_size(dst);
+ if (!src_len || !dst_len)
+ return -EINVAL;
+
+ if (iv_len != crypto_lskcipher_ivsize(tfm))
+ return -EINVAL;
+
+ psrc = __bpf_dynptr_data(src, src_len);
+ if (!psrc)
+ return -EINVAL;
+ pdst = __bpf_dynptr_data_rw(dst, dst_len);
+ if (!pdst)
+ return -EINVAL;
+
+ piv = iv_len ? __bpf_dynptr_data_rw(iv, iv_len) : NULL;
+ if (iv_len && !piv)
+ return -EINVAL;
+
+ err = decrypt ? crypto_lskcipher_decrypt(tfm, psrc, pdst, src_len, piv)
+ : crypto_lskcipher_encrypt(tfm, psrc, pdst, src_len, piv);
+
+ return err;
+}
+
+/**
+ * bpf_crypto_lskcipher_decrypt() - Decrypt buffer using configured context and IV provided.
+ * @ctx: The crypto context being used. The ctx must be a trusted pointer.
+ * @src: bpf_dynptr to the encrypted data. Must be a trusted pointer.
+ * @dst: bpf_dynptr to the buffer where to store the result. Must be a trusted pointer.
+ * @iv: bpf_dynptr to IV data to be used by decryptor.
+ *
+ * Decrypts provided buffer using IV data and the crypto context. Crypto context must be configured.
+ */
+__bpf_kfunc int bpf_crypto_lskcipher_decrypt(struct bpf_crypto_lskcipher_ctx *ctx,
+ const struct bpf_dynptr_kern *src,
+ struct bpf_dynptr_kern *dst,
+ struct bpf_dynptr_kern *iv)
+{
+ return bpf_crypto_lskcipher_crypt(ctx->tfm, src, dst, iv, true);
+}
+
+/**
+ * bpf_crypto_lskcipher_encrypt() - Encrypt buffer using configured context and IV provided.
+ * @ctx: The crypto context being used. The ctx must be a trusted pointer.
+ * @src: bpf_dynptr to the plain data. Must be a trusted pointer.
+ * @dst: bpf_dynptr to buffer where to store the result. Must be a trusted pointer.
+ * @iv: bpf_dynptr to IV data to be used by decryptor.
+ *
+ * Encrypts provided buffer using IV data and the crypto context. Crypto context must be configured.
+ */
+__bpf_kfunc int bpf_crypto_lskcipher_encrypt(struct bpf_crypto_lskcipher_ctx *ctx,
+ const struct bpf_dynptr_kern *src,
+ struct bpf_dynptr_kern *dst,
+ struct bpf_dynptr_kern *iv)
+{
+ return bpf_crypto_lskcipher_crypt(ctx->tfm, src, dst, iv, false);
+}
+
+__bpf_kfunc_end_defs();
+
+BTF_SET8_START(crypt_lskcipher_init_kfunc_btf_ids)
+BTF_ID_FLAGS(func, bpf_crypto_lskcipher_ctx_create, KF_ACQUIRE | KF_RET_NULL | KF_SLEEPABLE)
+BTF_ID_FLAGS(func, bpf_crypto_lskcipher_ctx_release, KF_RELEASE)
+BTF_ID_FLAGS(func, bpf_crypto_lskcipher_ctx_acquire, KF_ACQUIRE | KF_TRUSTED_ARGS)
+BTF_SET8_END(crypt_lskcipher_init_kfunc_btf_ids)
+
+static const struct btf_kfunc_id_set crypt_lskcipher_init_kfunc_set = {
+ .owner = THIS_MODULE,
+ .set = &crypt_lskcipher_init_kfunc_btf_ids,
+};
+
+BTF_SET8_START(crypt_lskcipher_kfunc_btf_ids)
+BTF_ID_FLAGS(func, bpf_crypto_lskcipher_decrypt, KF_RCU)
+BTF_ID_FLAGS(func, bpf_crypto_lskcipher_encrypt, KF_RCU)
+BTF_SET8_END(crypt_lskcipher_kfunc_btf_ids)
+
+static const struct btf_kfunc_id_set crypt_lskcipher_kfunc_set = {
+ .owner = THIS_MODULE,
+ .set = &crypt_lskcipher_kfunc_btf_ids,
+};
+
+BTF_ID_LIST(crypto_lskcipher_dtor_ids)
+BTF_ID(struct, bpf_crypto_lskcipher_ctx)
+BTF_ID(func, bpf_crypto_lskcipher_ctx_release)
+
+static int __init crypto_lskcipher_kfunc_init(void)
+{
+ int ret;
+ const struct btf_id_dtor_kfunc crypto_lskcipher_dtors[] = {
+ {
+ .btf_id = crypto_lskcipher_dtor_ids[0],
+ .kfunc_btf_id = crypto_lskcipher_dtor_ids[1]
+ },
+ };
+
+ ret = register_btf_kfunc_id_set(BPF_PROG_TYPE_SCHED_CLS, &crypt_lskcipher_kfunc_set);
+ ret = ret ?: register_btf_kfunc_id_set(BPF_PROG_TYPE_SCHED_ACT, &crypt_lskcipher_kfunc_set);
+ ret = ret ?: register_btf_kfunc_id_set(BPF_PROG_TYPE_XDP, &crypt_lskcipher_kfunc_set);
+ ret = ret ?: register_btf_kfunc_id_set(BPF_PROG_TYPE_UNSPEC,
+ &crypt_lskcipher_init_kfunc_set);
+ return ret ?: register_btf_id_dtor_kfuncs(crypto_lskcipher_dtors,
+ ARRAY_SIZE(crypto_lskcipher_dtors),
+ THIS_MODULE);
+}
+
+late_initcall(crypto_lskcipher_kfunc_init);
diff --git a/kernel/bpf/helpers.c b/kernel/bpf/helpers.c
index b45a8381f9bd..b73314c0124e 100644
--- a/kernel/bpf/helpers.c
+++ b/kernel/bpf/helpers.c
@@ -1436,7 +1436,7 @@ static const struct bpf_func_proto bpf_kptr_xchg_proto = {
#define DYNPTR_SIZE_MASK 0xFFFFFF
#define DYNPTR_RDONLY_BIT BIT(31)

-static bool __bpf_dynptr_is_rdonly(const struct bpf_dynptr_kern *ptr)
+bool __bpf_dynptr_is_rdonly(const struct bpf_dynptr_kern *ptr)
{
return ptr->size & DYNPTR_RDONLY_BIT;
}
diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
index 7c3461b89513..a20324ea990b 100644
--- a/kernel/bpf/verifier.c
+++ b/kernel/bpf/verifier.c
@@ -5558,6 +5558,7 @@ BTF_ID(struct, cgroup)
#endif
BTF_ID(struct, bpf_cpumask)
BTF_ID(struct, task_struct)
+BTF_ID(struct, bpf_crypto_lskcipher_ctx)
BTF_SET_END(rcu_protected_types)

static bool rcu_protected_object(const struct btf *btf, u32 btf_id)
--
2.39.3



2023-11-19 00:33:02

by Vadim Fedorenko

[permalink] [raw]
Subject: [PATCH bpf-next v5 2/2] selftests: bpf: crypto skcipher algo selftests

Add simple tc hook selftests to show the way to work with new crypto
BPF API. Some weird structre and map are added to setup program to make
verifier happy about dynptr initialization from memory. Simple AES-ECB
algo is used to demonstrate encryption and decryption of fixed size
buffers.

Signed-off-by: Vadim Fedorenko <[email protected]>
---
v4 -> v5:
- adjust selftests to use new naming
- restore tests on aarch64 and s390 as no sg lists are used
v3 -> v4:
- adjust selftests to use new syntax of helpers
- add tests for acquire and release
v2 -> v3:
- disable tests on s390 and aarch64 because of unknown Fatal exception
in sg_init_one
v1 -> v2:
- add CONFIG_CRYPTO_AES and CONFIG_CRYPTO_ECB to selftest build config
suggested by Daniel
---
tools/testing/selftests/bpf/config | 3 +
.../selftests/bpf/prog_tests/crypto_sanity.c | 148 ++++++++++++++
.../selftests/bpf/progs/crypto_common.h | 69 +++++++
.../selftests/bpf/progs/crypto_sanity.c | 193 ++++++++++++++++++
4 files changed, 413 insertions(+)
create mode 100644 tools/testing/selftests/bpf/prog_tests/crypto_sanity.c
create mode 100644 tools/testing/selftests/bpf/progs/crypto_common.h
create mode 100644 tools/testing/selftests/bpf/progs/crypto_sanity.c

diff --git a/tools/testing/selftests/bpf/config b/tools/testing/selftests/bpf/config
index 3ec5927ec3e5..81e521e9c0e9 100644
--- a/tools/testing/selftests/bpf/config
+++ b/tools/testing/selftests/bpf/config
@@ -14,6 +14,9 @@ CONFIG_CGROUP_BPF=y
CONFIG_CRYPTO_HMAC=y
CONFIG_CRYPTO_SHA256=y
CONFIG_CRYPTO_USER_API_HASH=y
+CONFIG_CRYPTO_SKCIPHER=y
+CONFIG_CRYPTO_ECB=y
+CONFIG_CRYPTO_AES=y
CONFIG_DEBUG_INFO=y
CONFIG_DEBUG_INFO_BTF=y
CONFIG_DEBUG_INFO_DWARF4=y
diff --git a/tools/testing/selftests/bpf/prog_tests/crypto_sanity.c b/tools/testing/selftests/bpf/prog_tests/crypto_sanity.c
new file mode 100644
index 000000000000..eb2cf7677797
--- /dev/null
+++ b/tools/testing/selftests/bpf/prog_tests/crypto_sanity.c
@@ -0,0 +1,148 @@
+// SPDX-License-Identifier: GPL-2.0
+/* Copyright (c) 2023 Meta Platforms, Inc. and affiliates. */
+
+#include <sys/types.h>
+#include <sys/socket.h>
+#include <net/if.h>
+#include <linux/in6.h>
+
+#include "test_progs.h"
+#include "network_helpers.h"
+#include "crypto_sanity.skel.h"
+
+#define NS_TEST "crypto_sanity_ns"
+#define IPV6_IFACE_ADDR "face::1"
+#define UDP_TEST_PORT 7777
+static const char plain_text[] = "stringtoencrypt0";
+static const char crypted_data[] = "\x5B\x59\x39\xEA\xD9\x7A\x2D\xAD\xA7\xE0\x43" \
+ "\x37\x8A\x77\x17\xB2";
+
+void test_crypto_sanity(void)
+{
+ LIBBPF_OPTS(bpf_tc_hook, qdisc_hook, .attach_point = BPF_TC_EGRESS);
+ LIBBPF_OPTS(bpf_tc_opts, tc_attach_enc);
+ LIBBPF_OPTS(bpf_tc_opts, tc_attach_dec);
+ LIBBPF_OPTS(bpf_test_run_opts, opts,
+ .repeat = 1,
+ );
+ struct nstoken *nstoken = NULL;
+ struct crypto_sanity *skel;
+ struct sockaddr_in6 addr;
+ int sockfd, err, pfd;
+ socklen_t addrlen;
+
+ skel = crypto_sanity__open();
+ if (!ASSERT_OK_PTR(skel, "skel open"))
+ return;
+
+ bpf_program__set_autoload(skel->progs.crypto_accuire, true);
+
+ err = crypto_sanity__load(skel);
+ if (!ASSERT_ERR(err, "crypto_accuire unexpected load success"))
+ goto fail;
+
+ crypto_sanity__destroy(skel);
+
+ skel = crypto_sanity__open();
+ if (!ASSERT_OK_PTR(skel, "skel open"))
+ return;
+
+ bpf_program__set_autoload(skel->progs.crypto_accuire, false);
+
+ SYS(fail, "ip netns add %s", NS_TEST);
+ SYS(fail, "ip -net %s -6 addr add %s/128 dev lo nodad", NS_TEST, IPV6_IFACE_ADDR);
+ SYS(fail, "ip -net %s link set dev lo up", NS_TEST);
+
+ err = crypto_sanity__load(skel);
+ if (!ASSERT_OK(err, "crypto_sanity__load"))
+ goto fail;
+
+ nstoken = open_netns(NS_TEST);
+ if (!ASSERT_OK_PTR(nstoken, "open_netns"))
+ goto fail;
+
+ qdisc_hook.ifindex = if_nametoindex("lo");
+ if (!ASSERT_GT(qdisc_hook.ifindex, 0, "if_nametoindex lo"))
+ goto fail;
+
+ err = crypto_sanity__attach(skel);
+ if (!ASSERT_OK(err, "crypto_sanity__attach"))
+ goto fail;
+
+ pfd = bpf_program__fd(skel->progs.crypto_release);
+ if (!ASSERT_GT(pfd, 0, "crypto_release fd"))
+ goto fail;
+
+ err = bpf_prog_test_run_opts(pfd, &opts);
+ if (!ASSERT_OK(err, "crypto_release") ||
+ !ASSERT_OK(opts.retval, "crypto_release retval"))
+ goto fail;
+
+ pfd = bpf_program__fd(skel->progs.skb_crypto_setup);
+ if (!ASSERT_GT(pfd, 0, "skb_crypto_setup fd"))
+ goto fail;
+
+ err = bpf_prog_test_run_opts(pfd, &opts);
+ if (!ASSERT_OK(err, "skb_crypto_setup") ||
+ !ASSERT_OK(opts.retval, "skb_crypto_setup retval"))
+ goto fail;
+
+ if (!ASSERT_OK(skel->bss->status, "skb_crypto_setup status"))
+ goto fail;
+
+ err = bpf_tc_hook_create(&qdisc_hook);
+ if (!ASSERT_OK(err, "create qdisc hook"))
+ goto fail;
+
+ addrlen = sizeof(addr);
+ err = make_sockaddr(AF_INET6, IPV6_IFACE_ADDR, UDP_TEST_PORT,
+ (void *)&addr, &addrlen);
+ if (!ASSERT_OK(err, "make_sockaddr"))
+ goto fail;
+
+ tc_attach_dec.prog_fd = bpf_program__fd(skel->progs.decrypt_sanity);
+ err = bpf_tc_attach(&qdisc_hook, &tc_attach_dec);
+ if (!ASSERT_OK(err, "attach decrypt filter"))
+ goto fail;
+
+ sockfd = socket(AF_INET6, SOCK_DGRAM, 0);
+ if (!ASSERT_NEQ(sockfd, -1, "decrypt socket"))
+ goto fail;
+ err = sendto(sockfd, crypted_data, 16, 0, (void *)&addr, addrlen);
+ close(sockfd);
+ if (!ASSERT_EQ(err, 16, "decrypt send"))
+ goto fail;
+
+ bpf_tc_detach(&qdisc_hook, &tc_attach_dec);
+ if (!ASSERT_OK(skel->bss->status, "decrypt status"))
+ goto fail;
+ if (!ASSERT_STRNEQ(skel->bss->dst, plain_text, sizeof(plain_text), "decrypt"))
+ goto fail;
+
+ tc_attach_enc.prog_fd = bpf_program__fd(skel->progs.encrypt_sanity);
+ err = bpf_tc_attach(&qdisc_hook, &tc_attach_enc);
+ if (!ASSERT_OK(err, "attach encrypt filter"))
+ goto fail;
+
+ sockfd = socket(AF_INET6, SOCK_DGRAM, 0);
+ if (!ASSERT_NEQ(sockfd, -1, "encrypt socket"))
+ goto fail;
+ err = sendto(sockfd, plain_text, 16, 0, (void *)&addr, addrlen);
+ close(sockfd);
+ if (!ASSERT_EQ(err, 16, "encrypt send"))
+ goto fail;
+
+ bpf_tc_detach(&qdisc_hook, &tc_attach_enc);
+ if (!ASSERT_OK(skel->bss->status, "encrypt status"))
+ goto fail;
+ if (!ASSERT_STRNEQ(skel->bss->dst, crypted_data, sizeof(crypted_data), "encrypt"))
+ goto fail;
+
+fail:
+ if (nstoken) {
+ bpf_tc_hook_destroy(&qdisc_hook);
+ close_netns(nstoken);
+ }
+ SYS_NOFAIL("ip netns del " NS_TEST " &> /dev/null");
+ crypto_sanity__destroy(skel);
+}
diff --git a/tools/testing/selftests/bpf/progs/crypto_common.h b/tools/testing/selftests/bpf/progs/crypto_common.h
new file mode 100644
index 000000000000..83cec18c4df7
--- /dev/null
+++ b/tools/testing/selftests/bpf/progs/crypto_common.h
@@ -0,0 +1,69 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/* Copyright (c) 2023 Meta Platforms, Inc. and affiliates. */
+
+#ifndef _CRYPTO_COMMON_H
+#define _CRYPTO_COMMON_H
+
+#include "errno.h"
+#include <stdbool.h>
+
+struct bpf_crypto_lskcipher_ctx *bpf_crypto_lskcipher_ctx_create(const char *algo__str,
+ const struct bpf_dynptr *key,
+ int *err) __ksym;
+struct bpf_crypto_lskcipher_ctx *bpf_crypto_lskcipher_ctx_acquire(struct bpf_crypto_lskcipher_ctx *ctx) __ksym;
+void bpf_crypto_lskcipher_ctx_release(struct bpf_crypto_lskcipher_ctx *ctx) __ksym;
+int bpf_crypto_lskcipher_encrypt(struct bpf_crypto_lskcipher_ctx *ctx,
+ const struct bpf_dynptr *src, struct bpf_dynptr *dst,
+ struct bpf_dynptr *iv) __ksym;
+int bpf_crypto_lskcipher_decrypt(struct bpf_crypto_lskcipher_ctx *ctx,
+ const struct bpf_dynptr *src, struct bpf_dynptr *dst,
+ struct bpf_dynptr *iv) __ksym;
+
+struct __crypto_lskcipher_ctx_value {
+ struct bpf_crypto_lskcipher_ctx __kptr * ctx;
+};
+
+struct array_map {
+ __uint(type, BPF_MAP_TYPE_ARRAY);
+ __type(key, int);
+ __type(value, struct __crypto_lskcipher_ctx_value);
+ __uint(max_entries, 1);
+} __crypto_lskcipher_ctx_map SEC(".maps");
+
+static inline struct __crypto_lskcipher_ctx_value *crypto_lskcipher_ctx_value_lookup(void)
+{
+ u32 key = 0;
+
+ return bpf_map_lookup_elem(&__crypto_lskcipher_ctx_map, &key);
+}
+
+static inline int crypto_lskcipher_ctx_insert(struct bpf_crypto_lskcipher_ctx *ctx)
+{
+ struct __crypto_lskcipher_ctx_value local, *v;
+ struct bpf_crypto_lskcipher_ctx *old;
+ u32 key = 0;
+ int err;
+
+ local.ctx = NULL;
+ err = bpf_map_update_elem(&__crypto_lskcipher_ctx_map, &key, &local, 0);
+ if (err) {
+ bpf_crypto_lskcipher_ctx_release(ctx);
+ return err;
+ }
+
+ v = bpf_map_lookup_elem(&__crypto_lskcipher_ctx_map, &key);
+ if (!v) {
+ bpf_crypto_lskcipher_ctx_release(ctx);
+ return -ENOENT;
+ }
+
+ old = bpf_kptr_xchg(&v->ctx, ctx);
+ if (old) {
+ bpf_crypto_lskcipher_ctx_release(old);
+ return -EEXIST;
+ }
+
+ return 0;
+}
+
+#endif /* _CRYPTO_COMMON_H */
diff --git a/tools/testing/selftests/bpf/progs/crypto_sanity.c b/tools/testing/selftests/bpf/progs/crypto_sanity.c
new file mode 100644
index 000000000000..191c954e9d28
--- /dev/null
+++ b/tools/testing/selftests/bpf/progs/crypto_sanity.c
@@ -0,0 +1,193 @@
+// SPDX-License-Identifier: GPL-2.0
+/* Copyright (c) 2023 Meta Platforms, Inc. and affiliates. */
+
+#include "vmlinux.h"
+#include "bpf_tracing_net.h"
+#include <bpf/bpf_helpers.h>
+#include <bpf/bpf_endian.h>
+#include <bpf/bpf_tracing.h>
+#include "bpf_misc.h"
+#include "bpf_kfuncs.h"
+#include "crypto_common.h"
+
+#define UDP_TEST_PORT 7777
+unsigned char crypto_key[16] = "testtest12345678";
+const char crypto_algo[9] = "ecb(aes)";
+char dst[32] = {};
+int status;
+
+static int skb_dynptr_validate(struct __sk_buff *skb, struct bpf_dynptr *psrc)
+{
+ struct ipv6hdr ip6h;
+ struct udphdr udph;
+ u32 offset;
+
+ if (skb->protocol != __bpf_constant_htons(ETH_P_IPV6))
+ return -1;
+
+ if (bpf_skb_load_bytes(skb, ETH_HLEN, &ip6h, sizeof(ip6h)))
+ return -1;
+
+ if (ip6h.nexthdr != IPPROTO_UDP)
+ return -1;
+
+ if (bpf_skb_load_bytes(skb, ETH_HLEN + sizeof(ip6h), &udph, sizeof(udph)))
+ return -1;
+
+ if (udph.dest != __bpf_constant_htons(UDP_TEST_PORT))
+ return -1;
+
+ offset = ETH_HLEN + sizeof(ip6h) + sizeof(udph);
+ if (skb->len < offset + 16)
+ return -1;
+
+ bpf_dynptr_from_skb(skb, 0, psrc);
+ bpf_dynptr_adjust(psrc, offset, offset + 16);
+
+ return 0;
+}
+
+SEC("fentry.s/bpf_fentry_test1")
+int BPF_PROG(skb_crypto_setup)
+{
+ struct bpf_crypto_lskcipher_ctx *cctx;
+ struct bpf_dynptr key = {};
+ int err = 0;
+
+ status = 0;
+
+ bpf_dynptr_from_mem(crypto_key, sizeof(crypto_key), 0, &key);
+ cctx = bpf_crypto_lskcipher_ctx_create(crypto_algo, &key, &err);
+
+ if (!cctx) {
+ status = err;
+ return 0;
+ }
+
+ err = crypto_lskcipher_ctx_insert(cctx);
+ if (err && err != -EEXIST)
+ status = err;
+
+ return 0;
+}
+
+SEC("fentry.s/bpf_fentry_test1")
+int BPF_PROG(crypto_release)
+{
+ struct bpf_crypto_lskcipher_ctx *cctx;
+ struct bpf_dynptr key = {};
+ int err = 0;
+
+ status = 0;
+
+ bpf_dynptr_from_mem(crypto_key, sizeof(crypto_key), 0, &key);
+ cctx = bpf_crypto_lskcipher_ctx_create(crypto_algo, &key, &err);
+
+ if (!cctx) {
+ status = err;
+ return 0;
+ }
+
+ bpf_crypto_lskcipher_ctx_release(cctx);
+
+ return 0;
+}
+
+SEC("?fentry.s/bpf_fentry_test1")
+__failure __msg("Unreleased reference")
+int BPF_PROG(crypto_accuire)
+{
+ struct bpf_crypto_lskcipher_ctx *cctx;
+ struct bpf_dynptr key = {};
+ int err = 0;
+
+ status = 0;
+
+ bpf_dynptr_from_mem(crypto_key, sizeof(crypto_key), 0, &key);
+ cctx = bpf_crypto_lskcipher_ctx_create(crypto_algo, &key, &err);
+
+ if (!cctx) {
+ status = err;
+ return 0;
+ }
+
+ cctx = bpf_crypto_lskcipher_ctx_acquire(cctx);
+ if (!cctx)
+ return -EINVAL;
+
+ bpf_crypto_lskcipher_ctx_release(cctx);
+
+ return 0;
+}
+
+SEC("tc")
+int decrypt_sanity(struct __sk_buff *skb)
+{
+ struct __crypto_lskcipher_ctx_value *v;
+ struct bpf_crypto_lskcipher_ctx *ctx;
+ struct bpf_dynptr psrc, pdst, iv;
+ int err;
+
+ err = skb_dynptr_validate(skb, &psrc);
+ if (err < 0) {
+ status = err;
+ return TC_ACT_SHOT;
+ }
+
+ v = crypto_lskcipher_ctx_value_lookup();
+ if (!v) {
+ status = -ENOENT;
+ return TC_ACT_SHOT;
+ }
+
+ ctx = v->ctx;
+ if (!ctx) {
+ status = -ENOENT;
+ return TC_ACT_SHOT;
+ }
+
+ bpf_dynptr_from_mem(dst, sizeof(dst), 0, &pdst);
+ bpf_dynptr_from_mem(dst, 0, 0, &iv);
+
+ status = bpf_crypto_lskcipher_decrypt(ctx, &psrc, &pdst, &iv);
+
+ return TC_ACT_SHOT;
+}
+
+SEC("tc")
+int encrypt_sanity(struct __sk_buff *skb)
+{
+ struct __crypto_lskcipher_ctx_value *v;
+ struct bpf_crypto_lskcipher_ctx *ctx;
+ struct bpf_dynptr psrc, pdst, iv;
+ int err;
+
+ status = 0;
+
+ err = skb_dynptr_validate(skb, &psrc);
+ if (err < 0) {
+ status = err;
+ return TC_ACT_SHOT;
+ }
+
+ v = crypto_lskcipher_ctx_value_lookup();
+ if (!v) {
+ status = -ENOENT;
+ return TC_ACT_SHOT;
+ }
+
+ ctx = v->ctx;
+ if (!ctx) {
+ status = -ENOENT;
+ return TC_ACT_SHOT;
+ }
+
+ bpf_dynptr_from_mem(dst, sizeof(dst), 0, &pdst);
+ bpf_dynptr_from_mem(dst, 0, 0, &iv);
+
+ status = bpf_crypto_lskcipher_encrypt(ctx, &psrc, &pdst, &iv);
+
+ return TC_ACT_SHOT;
+}
+
+char __license[] SEC("license") = "GPL";
--
2.39.3


2023-11-19 00:33:08

by Alexei Starovoitov

[permalink] [raw]
Subject: Re: [PATCH bpf-next v5 1/2] bpf: add skcipher API support to TC/XDP programs

On Sat, Nov 18, 2023 at 2:55 PM Vadim Fedorenko <[email protected]> wrote:
>
> +/**
> + * struct bpf_crypto_lskcipher_ctx - refcounted BPF sync skcipher context structure
> + * @tfm: The pointer to crypto_sync_skcipher struct.
> + * @rcu: The RCU head used to free the crypto context with RCU safety.
> + * @usage: Object reference counter. When the refcount goes to 0, the
> + * memory is released back to the BPF allocator, which provides
> + * RCU safety.
> + */
> +struct bpf_crypto_lskcipher_ctx {
> + struct crypto_lskcipher *tfm;
> + struct rcu_head rcu;
> + refcount_t usage;
> +};
> +
> +__bpf_kfunc_start_defs();
> +
> +/**
> + * bpf_crypto_lskcipher_ctx_create() - Create a mutable BPF crypto context.

Let's drop 'lskcipher' from the kfunc names and ctx struct.
bpf users don't need to know the internal implementation details.
bpf_crypto_encrypt/decrypt() is clear enough.

2023-11-19 00:33:19

by Vadim Fedorenko

[permalink] [raw]
Subject: Re: [PATCH bpf-next v5 1/2] bpf: add skcipher API support to TC/XDP programs

On 18/11/2023 18:23, Alexei Starovoitov wrote:
> On Sat, Nov 18, 2023 at 2:55 PM Vadim Fedorenko <[email protected]> wrote:
>>
>> +/**
>> + * struct bpf_crypto_lskcipher_ctx - refcounted BPF sync skcipher context structure
>> + * @tfm: The pointer to crypto_sync_skcipher struct.
>> + * @rcu: The RCU head used to free the crypto context with RCU safety.
>> + * @usage: Object reference counter. When the refcount goes to 0, the
>> + * memory is released back to the BPF allocator, which provides
>> + * RCU safety.
>> + */
>> +struct bpf_crypto_lskcipher_ctx {
>> + struct crypto_lskcipher *tfm;
>> + struct rcu_head rcu;
>> + refcount_t usage;
>> +};
>> +
>> +__bpf_kfunc_start_defs();
>> +
>> +/**
>> + * bpf_crypto_lskcipher_ctx_create() - Create a mutable BPF crypto context.
>
> Let's drop 'lskcipher' from the kfunc names and ctx struct.
> bpf users don't need to know the internal implementation details.
> bpf_crypto_encrypt/decrypt() is clear enough.

The only reason I added it was the existence of AEAD subset of crypto
API. And this subset can also be implemented in bpf later, and there
will be inconsistency in naming then if we add aead in future names.
WDYT?

2023-11-19 00:33:31

by Alexei Starovoitov

[permalink] [raw]
Subject: Re: [PATCH bpf-next v5 1/2] bpf: add skcipher API support to TC/XDP programs

On Sat, Nov 18, 2023 at 3:32 PM Vadim Fedorenko
<[email protected]> wrote:
>
> On 18/11/2023 18:23, Alexei Starovoitov wrote:
> > On Sat, Nov 18, 2023 at 2:55 PM Vadim Fedorenko <[email protected]> wrote:
> >>
> >> +/**
> >> + * struct bpf_crypto_lskcipher_ctx - refcounted BPF sync skcipher context structure
> >> + * @tfm: The pointer to crypto_sync_skcipher struct.
> >> + * @rcu: The RCU head used to free the crypto context with RCU safety.
> >> + * @usage: Object reference counter. When the refcount goes to 0, the
> >> + * memory is released back to the BPF allocator, which provides
> >> + * RCU safety.
> >> + */
> >> +struct bpf_crypto_lskcipher_ctx {
> >> + struct crypto_lskcipher *tfm;
> >> + struct rcu_head rcu;
> >> + refcount_t usage;
> >> +};
> >> +
> >> +__bpf_kfunc_start_defs();
> >> +
> >> +/**
> >> + * bpf_crypto_lskcipher_ctx_create() - Create a mutable BPF crypto context.
> >
> > Let's drop 'lskcipher' from the kfunc names and ctx struct.
> > bpf users don't need to know the internal implementation details.
> > bpf_crypto_encrypt/decrypt() is clear enough.
>
> The only reason I added it was the existence of AEAD subset of crypto
> API. And this subset can also be implemented in bpf later, and there
> will be inconsistency in naming then if we add aead in future names.
> WDYT?

You mean future async apis ? Just bpf_crypto_encrypt_async() ?

2023-11-19 00:33:38

by Vadim Fedorenko

[permalink] [raw]
Subject: Re: [PATCH bpf-next v5 1/2] bpf: add skcipher API support to TC/XDP programs

On 18/11/2023 18:35, Alexei Starovoitov wrote:
> On Sat, Nov 18, 2023 at 3:32 PM Vadim Fedorenko
> <[email protected]> wrote:
>>
>> On 18/11/2023 18:23, Alexei Starovoitov wrote:
>>> On Sat, Nov 18, 2023 at 2:55 PM Vadim Fedorenko <[email protected]> wrote:
>>>>
>>>> +/**
>>>> + * struct bpf_crypto_lskcipher_ctx - refcounted BPF sync skcipher context structure
>>>> + * @tfm: The pointer to crypto_sync_skcipher struct.
>>>> + * @rcu: The RCU head used to free the crypto context with RCU safety.
>>>> + * @usage: Object reference counter. When the refcount goes to 0, the
>>>> + * memory is released back to the BPF allocator, which provides
>>>> + * RCU safety.
>>>> + */
>>>> +struct bpf_crypto_lskcipher_ctx {
>>>> + struct crypto_lskcipher *tfm;
>>>> + struct rcu_head rcu;
>>>> + refcount_t usage;
>>>> +};
>>>> +
>>>> +__bpf_kfunc_start_defs();
>>>> +
>>>> +/**
>>>> + * bpf_crypto_lskcipher_ctx_create() - Create a mutable BPF crypto context.
>>>
>>> Let's drop 'lskcipher' from the kfunc names and ctx struct.
>>> bpf users don't need to know the internal implementation details.
>>> bpf_crypto_encrypt/decrypt() is clear enough.
>>
>> The only reason I added it was the existence of AEAD subset of crypto
>> API. And this subset can also be implemented in bpf later, and there
>> will be inconsistency in naming then if we add aead in future names.
>> WDYT?
>
> You mean future async apis ? Just bpf_crypto_encrypt_async() ?

Well, not only async. It's about Authenticated Encryption With
Associated Data (AEAD) Cipher API defined in crypto/aead.h. It's
ciphers with additional hmac function, like
'authenc(hmac(sha256),cbc(aes))'. It has very similar API with only
difference of having Authenticated data in the encrypted block.

I'm not sure though if there is explicit sync implementation, but I do
believe async ciphers can be filtered out for this interface too.

2023-11-19 18:40:33

by Alexei Starovoitov

[permalink] [raw]
Subject: Re: [PATCH bpf-next v5 1/2] bpf: add skcipher API support to TC/XDP programs

On Sat, Nov 18, 2023 at 3:46 PM Vadim Fedorenko
<[email protected]> wrote:
>
> On 18/11/2023 18:35, Alexei Starovoitov wrote:
> > On Sat, Nov 18, 2023 at 3:32 PM Vadim Fedorenko
> > <[email protected]> wrote:
> >>
> >> On 18/11/2023 18:23, Alexei Starovoitov wrote:
> >>> On Sat, Nov 18, 2023 at 2:55 PM Vadim Fedorenko <[email protected]> wrote:
> >>>>
> >>>> +/**
> >>>> + * struct bpf_crypto_lskcipher_ctx - refcounted BPF sync skcipher context structure
> >>>> + * @tfm: The pointer to crypto_sync_skcipher struct.
> >>>> + * @rcu: The RCU head used to free the crypto context with RCU safety.
> >>>> + * @usage: Object reference counter. When the refcount goes to 0, the
> >>>> + * memory is released back to the BPF allocator, which provides
> >>>> + * RCU safety.
> >>>> + */
> >>>> +struct bpf_crypto_lskcipher_ctx {
> >>>> + struct crypto_lskcipher *tfm;
> >>>> + struct rcu_head rcu;
> >>>> + refcount_t usage;
> >>>> +};
> >>>> +
> >>>> +__bpf_kfunc_start_defs();
> >>>> +
> >>>> +/**
> >>>> + * bpf_crypto_lskcipher_ctx_create() - Create a mutable BPF crypto context.
> >>>
> >>> Let's drop 'lskcipher' from the kfunc names and ctx struct.
> >>> bpf users don't need to know the internal implementation details.
> >>> bpf_crypto_encrypt/decrypt() is clear enough.
> >>
> >> The only reason I added it was the existence of AEAD subset of crypto
> >> API. And this subset can also be implemented in bpf later, and there
> >> will be inconsistency in naming then if we add aead in future names.
> >> WDYT?
> >
> > You mean future async apis ? Just bpf_crypto_encrypt_async() ?
>
> Well, not only async. It's about Authenticated Encryption With
> Associated Data (AEAD) Cipher API defined in crypto/aead.h. It's
> ciphers with additional hmac function, like
> 'authenc(hmac(sha256),cbc(aes))'. It has very similar API with only
> difference of having Authenticated data in the encrypted block.

and ? I'm not following what you're trying to say.
Where is the inconsistency ?
My point again is that lskcipher vs skcipher vs foo is an implementation
detail that shouldn't be exposed in the name.

2023-11-19 22:32:15

by Alexei Starovoitov

[permalink] [raw]
Subject: Re: [PATCH bpf-next v5 2/2] selftests: bpf: crypto skcipher algo selftests

On Sat, Nov 18, 2023 at 2:55 PM Vadim Fedorenko <[email protected]> wrote:
>
> +
> +SEC("fentry.s/bpf_fentry_test1")
> +int BPF_PROG(skb_crypto_setup)
> +{
> + struct bpf_crypto_lskcipher_ctx *cctx;
> + struct bpf_dynptr key = {};
> + int err = 0;
> +
> + status = 0;
> +
> + bpf_dynptr_from_mem(crypto_key, sizeof(crypto_key), 0, &key);
> + cctx = bpf_crypto_lskcipher_ctx_create(crypto_algo, &key, &err);

Direct string will work here, right?
What's the reason to use global var?

2023-11-20 00:32:03

by Vadim Fedorenko

[permalink] [raw]
Subject: Re: [PATCH bpf-next v5 2/2] selftests: bpf: crypto skcipher algo selftests

On 19.11.2023 21:58, Alexei Starovoitov wrote:
> On Sat, Nov 18, 2023 at 2:55 PM Vadim Fedorenko <[email protected]> wrote:
>>
>> +
>> +SEC("fentry.s/bpf_fentry_test1")
>> +int BPF_PROG(skb_crypto_setup)
>> +{
>> + struct bpf_crypto_lskcipher_ctx *cctx;
>> + struct bpf_dynptr key = {};
>> + int err = 0;
>> +
>> + status = 0;
>> +
>> + bpf_dynptr_from_mem(crypto_key, sizeof(crypto_key), 0, &key);
>> + cctx = bpf_crypto_lskcipher_ctx_create(crypto_algo, &key, &err);
>
> Direct string will work here, right?
> What's the reason to use global var?

Mmm, yeah, should work. I'll update the test, thanks!

2023-11-20 00:32:12

by Vadim Fedorenko

[permalink] [raw]
Subject: Re: [PATCH bpf-next v5 1/2] bpf: add skcipher API support to TC/XDP programs

On 19.11.2023 16:56, Alexei Starovoitov wrote:
> On Sat, Nov 18, 2023 at 3:46 PM Vadim Fedorenko
> <[email protected]> wrote:
>>
>> On 18/11/2023 18:35, Alexei Starovoitov wrote:
>>> On Sat, Nov 18, 2023 at 3:32 PM Vadim Fedorenko
>>> <[email protected]> wrote:
>>>>
>>>> On 18/11/2023 18:23, Alexei Starovoitov wrote:
>>>>> On Sat, Nov 18, 2023 at 2:55 PM Vadim Fedorenko <[email protected]> wrote:
>>>>>>
>>>>>> +/**
>>>>>> + * struct bpf_crypto_lskcipher_ctx - refcounted BPF sync skcipher context structure
>>>>>> + * @tfm: The pointer to crypto_sync_skcipher struct.
>>>>>> + * @rcu: The RCU head used to free the crypto context with RCU safety.
>>>>>> + * @usage: Object reference counter. When the refcount goes to 0, the
>>>>>> + * memory is released back to the BPF allocator, which provides
>>>>>> + * RCU safety.
>>>>>> + */
>>>>>> +struct bpf_crypto_lskcipher_ctx {
>>>>>> + struct crypto_lskcipher *tfm;
>>>>>> + struct rcu_head rcu;
>>>>>> + refcount_t usage;
>>>>>> +};
>>>>>> +
>>>>>> +__bpf_kfunc_start_defs();
>>>>>> +
>>>>>> +/**
>>>>>> + * bpf_crypto_lskcipher_ctx_create() - Create a mutable BPF crypto context.
>>>>>
>>>>> Let's drop 'lskcipher' from the kfunc names and ctx struct.
>>>>> bpf users don't need to know the internal implementation details.
>>>>> bpf_crypto_encrypt/decrypt() is clear enough.
>>>>
>>>> The only reason I added it was the existence of AEAD subset of crypto
>>>> API. And this subset can also be implemented in bpf later, and there
>>>> will be inconsistency in naming then if we add aead in future names.
>>>> WDYT?
>>>
>>> You mean future async apis ? Just bpf_crypto_encrypt_async() ?
>>
>> Well, not only async. It's about Authenticated Encryption With
>> Associated Data (AEAD) Cipher API defined in crypto/aead.h. It's
>> ciphers with additional hmac function, like
>> 'authenc(hmac(sha256),cbc(aes))'. It has very similar API with only
>> difference of having Authenticated data in the encrypted block.
>
> and ? I'm not following what you're trying to say.
> Where is the inconsistency ?
> My point again is that lskcipher vs skcipher vs foo is an implementation
> detail that shouldn't be exposed in the name.

Well, I was trying to follow crypto subsystem naming. It might be easier for
users to understand what part of crypto API is supported by BPF kfuncs.

At the same we can agree that current implementation will be used for simple
buffer encryption/decryption and any further implementations will have additions
in the name of functions (like
bpf_crypto_aead_crypt/bpf_crypto_shash_final/bpf_crypto_scomp_compress).
It will be slightly inconsistent, but we will have to expose some implementation
details unfortunately. If you are ok with this way, I'm ok to implement it.

2023-11-20 02:31:37

by Alexei Starovoitov

[permalink] [raw]
Subject: Re: [PATCH bpf-next v5 1/2] bpf: add skcipher API support to TC/XDP programs

On Sun, Nov 19, 2023 at 4:22 PM Vadim Fedorenko
<[email protected]> wrote:
>
> On 19.11.2023 16:56, Alexei Starovoitov wrote:
> > On Sat, Nov 18, 2023 at 3:46 PM Vadim Fedorenko
> > <[email protected]> wrote:
> >>
> >> On 18/11/2023 18:35, Alexei Starovoitov wrote:
> >>> On Sat, Nov 18, 2023 at 3:32 PM Vadim Fedorenko
> >>> <[email protected]> wrote:
> >>>>
> >>>> On 18/11/2023 18:23, Alexei Starovoitov wrote:
> >>>>> On Sat, Nov 18, 2023 at 2:55 PM Vadim Fedorenko <[email protected]> wrote:
> >>>>>>
> >>>>>> +/**
> >>>>>> + * struct bpf_crypto_lskcipher_ctx - refcounted BPF sync skcipher context structure
> >>>>>> + * @tfm: The pointer to crypto_sync_skcipher struct.
> >>>>>> + * @rcu: The RCU head used to free the crypto context with RCU safety.
> >>>>>> + * @usage: Object reference counter. When the refcount goes to 0, the
> >>>>>> + * memory is released back to the BPF allocator, which provides
> >>>>>> + * RCU safety.
> >>>>>> + */
> >>>>>> +struct bpf_crypto_lskcipher_ctx {
> >>>>>> + struct crypto_lskcipher *tfm;
> >>>>>> + struct rcu_head rcu;
> >>>>>> + refcount_t usage;
> >>>>>> +};
> >>>>>> +
> >>>>>> +__bpf_kfunc_start_defs();
> >>>>>> +
> >>>>>> +/**
> >>>>>> + * bpf_crypto_lskcipher_ctx_create() - Create a mutable BPF crypto context.
> >>>>>
> >>>>> Let's drop 'lskcipher' from the kfunc names and ctx struct.
> >>>>> bpf users don't need to know the internal implementation details.
> >>>>> bpf_crypto_encrypt/decrypt() is clear enough.
> >>>>
> >>>> The only reason I added it was the existence of AEAD subset of crypto
> >>>> API. And this subset can also be implemented in bpf later, and there
> >>>> will be inconsistency in naming then if we add aead in future names.
> >>>> WDYT?
> >>>
> >>> You mean future async apis ? Just bpf_crypto_encrypt_async() ?
> >>
> >> Well, not only async. It's about Authenticated Encryption With
> >> Associated Data (AEAD) Cipher API defined in crypto/aead.h. It's
> >> ciphers with additional hmac function, like
> >> 'authenc(hmac(sha256),cbc(aes))'. It has very similar API with only
> >> difference of having Authenticated data in the encrypted block.
> >
> > and ? I'm not following what you're trying to say.
> > Where is the inconsistency ?
> > My point again is that lskcipher vs skcipher vs foo is an implementation
> > detail that shouldn't be exposed in the name.
>
> Well, I was trying to follow crypto subsystem naming. It might be easier for
> users to understand what part of crypto API is supported by BPF kfuncs.
>
> At the same we can agree that current implementation will be used for simple
> buffer encryption/decryption and any further implementations will have additions
> in the name of functions (like
> bpf_crypto_aead_crypt/bpf_crypto_shash_final/bpf_crypto_scomp_compress).
> It will be slightly inconsistent, but we will have to expose some implementation
> details unfortunately. If you are ok with this way, I'm ok to implement it.

but shash vs scomp is the name of the algo ? Didn't you use it as
the 1st arg to bpf_crypto_create() ?
Take a look at AF_ALG. It's able to express all kinds of cryptos
through the same socket abstraction without creating a new name for
every algo. Everything is read/write through the socket fd.
In our case it will be bpf_crypto_encrypt/decrypt() kfuncs.

2023-11-20 18:46:53

by Vadim Fedorenko

[permalink] [raw]
Subject: Re: [PATCH bpf-next v5 1/2] bpf: add skcipher API support to TC/XDP programs

On 20/11/2023 20:13, Alexei Starovoitov wrote:
> On Sun, Nov 19, 2023 at 4:22 PM Vadim Fedorenko
> <[email protected]> wrote:
>>
>> On 19.11.2023 16:56, Alexei Starovoitov wrote:
>>> On Sat, Nov 18, 2023 at 3:46 PM Vadim Fedorenko
>>> <[email protected]> wrote:
>>>>
>>>> On 18/11/2023 18:35, Alexei Starovoitov wrote:
>>>>> On Sat, Nov 18, 2023 at 3:32 PM Vadim Fedorenko
>>>>> <[email protected]> wrote:
>>>>>>
>>>>>> On 18/11/2023 18:23, Alexei Starovoitov wrote:
>>>>>>> On Sat, Nov 18, 2023 at 2:55 PM Vadim Fedorenko <[email protected]> wrote:
>>>>>>>>
>>>>>>>> +/**
>>>>>>>> + * struct bpf_crypto_lskcipher_ctx - refcounted BPF sync skcipher context structure
>>>>>>>> + * @tfm: The pointer to crypto_sync_skcipher struct.
>>>>>>>> + * @rcu: The RCU head used to free the crypto context with RCU safety.
>>>>>>>> + * @usage: Object reference counter. When the refcount goes to 0, the
>>>>>>>> + * memory is released back to the BPF allocator, which provides
>>>>>>>> + * RCU safety.
>>>>>>>> + */
>>>>>>>> +struct bpf_crypto_lskcipher_ctx {
>>>>>>>> + struct crypto_lskcipher *tfm;
>>>>>>>> + struct rcu_head rcu;
>>>>>>>> + refcount_t usage;
>>>>>>>> +};
>>>>>>>> +
>>>>>>>> +__bpf_kfunc_start_defs();
>>>>>>>> +
>>>>>>>> +/**
>>>>>>>> + * bpf_crypto_lskcipher_ctx_create() - Create a mutable BPF crypto context.
>>>>>>>
>>>>>>> Let's drop 'lskcipher' from the kfunc names and ctx struct.
>>>>>>> bpf users don't need to know the internal implementation details.
>>>>>>> bpf_crypto_encrypt/decrypt() is clear enough.
>>>>>>
>>>>>> The only reason I added it was the existence of AEAD subset of crypto
>>>>>> API. And this subset can also be implemented in bpf later, and there
>>>>>> will be inconsistency in naming then if we add aead in future names.
>>>>>> WDYT?
>>>>>
>>>>> You mean future async apis ? Just bpf_crypto_encrypt_async() ?
>>>>
>>>> Well, not only async. It's about Authenticated Encryption With
>>>> Associated Data (AEAD) Cipher API defined in crypto/aead.h. It's
>>>> ciphers with additional hmac function, like
>>>> 'authenc(hmac(sha256),cbc(aes))'. It has very similar API with only
>>>> difference of having Authenticated data in the encrypted block.
>>>
>>> and ? I'm not following what you're trying to say.
>>> Where is the inconsistency ?
>>> My point again is that lskcipher vs skcipher vs foo is an implementation
>>> detail that shouldn't be exposed in the name.
>>
>> Well, I was trying to follow crypto subsystem naming. It might be easier for
>> users to understand what part of crypto API is supported by BPF kfuncs.
>>
>> At the same we can agree that current implementation will be used for simple
>> buffer encryption/decryption and any further implementations will have additions
>> in the name of functions (like
>> bpf_crypto_aead_crypt/bpf_crypto_shash_final/bpf_crypto_scomp_compress).
>> It will be slightly inconsistent, but we will have to expose some implementation
>> details unfortunately. If you are ok with this way, I'm ok to implement it.
>
> but shash vs scomp is the name of the algo ? Didn't you use it as
> the 1st arg to bpf_crypto_create() ?
> Take a look at AF_ALG. It's able to express all kinds of cryptos
> through the same socket abstraction without creating a new name for
> every algo. Everything is read/write through the socket fd.
> In our case it will be bpf_crypto_encrypt/decrypt() kfuncs.

Ok, I got the idea. I'll make v6 more general, like AF_ALG, but it will
support only one type (skcipher) for now. Thanks!