On 12/3/23 11:02 AM, Vadim Fedorenko wrote:
+static const struct bpf_crypto_type *bpf_crypto_get_type(const char *name)
+{
+ const struct bpf_crypto_type *type = ERR_PTR(-ENOENT);
+ struct bpf_crypto_type_list *node;
+
+ down_read(&bpf_crypto_types_sem);
+ list_for_each_entry(node, &bpf_crypto_types, list) {
+ if (strcmp(node->type->name, name))
+ continue;
+
+ if (try_module_get(node->type->owner))
If I read patch 2 correctly, it is always built-in. I am not sure I understand
the module_put/get in this patch.
Well, yeah, right now it's built-in, but it can be easily converted to module
with it's own Kconfig option. Especially if we think about adding aead crypto
and using bpf in embedded setups with less amount of resources.
What code is missing to support module? It sounds like all codes are ready.
and does it really need a separate kconfig option? Can it depend on
CONFIG_BPF_SYSCALL and CONFIG_CRYPTO_SKCIPHER?
+BTF_SET8_START(crypt_init_kfunc_btf_ids)
+BTF_ID_FLAGS(func, bpf_crypto_ctx_create, KF_ACQUIRE | KF_RET_NULL |
KF_SLEEPABLE)
+BTF_ID_FLAGS(func, bpf_crypto_ctx_release, KF_RELEASE)
+BTF_ID_FLAGS(func, bpf_crypto_ctx_acquire, KF_ACQUIRE | KF_TRUSTED_ARGS)
Considering bpf_crypto_ctx is rcu protected, the acquire may use "KF_ACQUIRE |
KF_RCU | KF_RET_NULL" such that the bpf_crypto_ctx_acquire(ctx_from_map_value)
will work and the user will prepare checking NULL from day one.
Got it. What about create? Should it also include KF_RCU?
create should not need KF_RCU. The return value is a trusted/refcounted pointer.
It has a reg->ref_obj_id => is_trusted_reg().
