Received: by 2002:a05:7412:b795:b0:e2:908c:2ebd with SMTP id iv21csp69775rdb; Wed, 1 Nov 2023 17:31:26 -0700 (PDT) X-Google-Smtp-Source: AGHT+IFLE1KplkfEZkGzkX3vx+k8HvyXe4g6h1jAU0LJER95MJF/xUPhQ9ySqxtfAk+7UF9MW8dx X-Received: by 2002:a17:902:e5c5:b0:1cc:4d4e:bfb4 with SMTP id u5-20020a170902e5c500b001cc4d4ebfb4mr5644716plf.12.1698885085765; Wed, 01 Nov 2023 17:31:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1698885085; cv=none; d=google.com; s=arc-20160816; b=mQPsLnYPULLpljqqHThMtS3QCbOzPJGSMXeMdnP5hua9Yg0cHZ5hvLbHlrv2JZuI6D PeWqGnWf3ykrmSwsQQsO9fjvM8k1sMH+al4UBawSn7CxiPvTJNQpVweZ7kSZFHj/VH50 q4MbbeZY2yBM6p12SsVFxs53Ygb8fo0GzzQWaVMnomXG655OzwjpJRpU441Y2yILwzhB UyrAOIfapFonX9OdIFIi0fWvyM4B3a+v4p11bZ8TCeyyIdYaRYPoJux1D9zhBLiwPB69 i1wMx1ghMvTmW8MZRbIqz+e1dLZEYgmMcd9k5ZsF8oVHikcw3sAuubh5hcuhLfe5tdeP 17Wg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:cc:to:content-language:subject:mime-version:date :dkim-signature:message-id; bh=DYyCqd0cmrSjG084WqxLPqA2/nJgQp5TviiyD9gAa58=; fh=USsrfX/NGEiJBO03pjAcUOf5F2hWcWbqWMDHrfEuxJU=; b=FzhOcUk7xhyMfjRaV0GrjXWdWoe/i6zI1yiK7144juSoDmxhM21WQfjHbZbYF6GgKy biieVWY6jSYywjrd3obLIZeLS/QVkr7m3RyrIt/V2HOmrL0mZJf2Gu0EyafXx36rq58X YEEUX5VaBr7A0fYNqVZxXJ2NR9mFusPiJ/iDHtlObGjfpL97bXjS4ZkpPTv3wHnioA8V xc59ilD8Hbz3OPQgLjVQb+6HGSHlHgpYtQ8o2MCCfQihh19GiPKvZ8+BexwledigFhwf sFO4uSPWRZ9qtszqT31jN5FCGfUZYJKixoiavVoUCNjq/vCfRm6caUZSiS66FA+SdUC9 Dnbg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linux.dev header.s=key1 header.b=AfhTKVv5; spf=pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 23.128.96.35 as permitted sender) smtp.mailfrom=linux-crypto-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linux.dev Return-Path: Received: from groat.vger.email (groat.vger.email. [23.128.96.35]) by mx.google.com with ESMTPS id u7-20020a170902e5c700b001c5fc13fb2dsi3741138plf.294.2023.11.01.17.31.24 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 01 Nov 2023 17:31:25 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 23.128.96.35 as permitted sender) client-ip=23.128.96.35; Authentication-Results: mx.google.com; dkim=pass header.i=@linux.dev header.s=key1 header.b=AfhTKVv5; spf=pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 23.128.96.35 as permitted sender) smtp.mailfrom=linux-crypto-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linux.dev Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by groat.vger.email (Postfix) with ESMTP id B2DC980C6E87; Wed, 1 Nov 2023 17:31:16 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at groat.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230285AbjKBAbR (ORCPT + 99 others); Wed, 1 Nov 2023 20:31:17 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52184 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229727AbjKBAbR (ORCPT ); Wed, 1 Nov 2023 20:31:17 -0400 Received: from out-189.mta1.migadu.com (out-189.mta1.migadu.com [95.215.58.189]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 96DEA115 for ; Wed, 1 Nov 2023 17:31:07 -0700 (PDT) Message-ID: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1698885065; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=DYyCqd0cmrSjG084WqxLPqA2/nJgQp5TviiyD9gAa58=; b=AfhTKVv5CFyGMnt1TteJDVqyRwYnFzpW/gx22EfntCf3ITt2CV3DoB2gisZStZ8WttZEYi FRhowJlpq9vLvhONTC+qAOo32w/z8HpU0I2iinUSBgo74HivpSUMx9MMVpfE4DNC8tNKpC ewjCdoK5NZZ/P9iRlEUwAFyEF/vLPcs= Date: Thu, 2 Nov 2023 00:31:03 +0000 MIME-Version: 1.0 Subject: Re: [PATCH bpf-next v3 1/2] bpf: add skcipher API support to TC/XDP programs Content-Language: en-US To: Martin KaFai Lau Cc: bpf@vger.kernel.org, netdev@vger.kernel.org, linux-crypto@vger.kernel.org, Jakub Kicinski , Andrii Nakryiko , Alexei Starovoitov , Mykola Lysenko , Vadim Fedorenko , "David S. Miller" , Herbert Xu References: <20231031134900.1432945-1-vadfed@meta.com> <91a6d5a7-7b18-48a2-9a74-7c00509467f8@linux.dev> <4adea710-72ca-0908-d280-625bc3682aa1@linux.dev> X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Vadim Fedorenko In-Reply-To: <4adea710-72ca-0908-d280-625bc3682aa1@linux.dev> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Migadu-Flow: FLOW_OUT X-Spam-Status: No, score=-0.9 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on groat.vger.email Precedence: bulk List-ID: X-Mailing-List: linux-crypto@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (groat.vger.email [0.0.0.0]); Wed, 01 Nov 2023 17:31:17 -0700 (PDT) On 01.11.2023 22:59, Martin KaFai Lau wrote: > 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? Hmm... looks like SYNC_SKCIPHER_REQUEST_ON_STACK will help us. Ok, I'll change this part to use stack allocations.