Re: [PATCH bpf-next v3 1/2] bpf: add skcipher API support to TC/XDP programs

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 11/1/23 3:50 PM, Vadim Fedorenko wrote:
+static int bpf_crypto_skcipher_crypt(struct crypto_sync_skcipher *tfm,
+                     const struct bpf_dynptr_kern *src,
+                     struct bpf_dynptr_kern *dst,
+                     const struct bpf_dynptr_kern *iv,
+                     bool decrypt)
+{
+    struct skcipher_request *req = NULL;
+    struct scatterlist sgin, sgout;
+    int err;
+
+    if (crypto_sync_skcipher_get_flags(tfm) & CRYPTO_TFM_NEED_KEY)
+        return -EINVAL;
+
+    if (__bpf_dynptr_is_rdonly(dst))
+        return -EINVAL;
+
+    if (!__bpf_dynptr_size(dst) || !__bpf_dynptr_size(src))
+        return -EINVAL;
+
+    if (__bpf_dynptr_size(iv) != crypto_sync_skcipher_ivsize(tfm))
+        return -EINVAL;
+
+    req = skcipher_request_alloc(&tfm->base, GFP_ATOMIC);

Doing alloc per packet may kill performance. Is it possible to optimize it somehow? What is the usual size of the req (e.g. the example in the selftest)?


In ktls code aead_request is allocated every time encryption is invoked, see tls_decrypt_sg(), apparently per skb. Doesn't look like performance
killer. For selftest it's only sizeof(struct skcipher_request).

ktls is doing the en/decrypt on the userspace behalf to compensate the cost.

When this kfunc is used in xdp to decrypt a few bytes for each packet and then XDP_TX out, this extra alloc will be quite noticeable. If the size is usually small, can it be done in the stack memory?




[Index of Archives]     [Kernel]     [Gnu Classpath]     [Gnu Crypto]     [DM Crypt]     [Netfilter]     [Bugtraq]
  Powered by Linux