From nobody Thu Apr 9 13:31:30 2026 Received: from mail-pg1-f179.google.com (mail-pg1-f179.google.com [209.85.215.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3E2C834D393 for ; Mon, 9 Mar 2026 05:54:47 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.215.179 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773035688; cv=none; b=mDuxlH+q5Jv9KYwCu+IYb/J4KYXpEmuJyAw37XV8XGsw2RRVArla5z/2fT5wq/NS4kLtBSgr6Zj6taiVmLh7AUdMNg0xAH3giOvqLgiEr9Vf2eXL0Div1kQ6esCA99G7plftnPfWWI1hBBU6+iMJl6cYeX+8xnBEoyFLJIoj88k= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773035688; c=relaxed/simple; bh=UreViDwj5CK4brJrjfQ7EURHubCS5eOib6jZhMepOdk=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=nxd7F3rRdFAd1OxtCC2Ocn2fRN8Z3ZKeNQigPvjRn9X6wl8xQlswySLERoitaoqaoV1MtVghHpZUAVpBLAIBv/X4xRR0OUcnafKVMlVE9hYAepIpErqGjabcyrhEyaSitPLkEdZpeu36KyntGEx5Ut9SOHh2gjCcmRH8MaJO6XI= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=diN4NXLb; arc=none smtp.client-ip=209.85.215.179 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="diN4NXLb" Received: by mail-pg1-f179.google.com with SMTP id 41be03b00d2f7-c73aabd620bso944522a12.1 for ; Sun, 08 Mar 2026 22:54:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1773035687; x=1773640487; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=+eXVlNI+VPppaY/morooabCwuSYEtf9ABnZ29jfqnh4=; b=diN4NXLbF4APbkdr50c/3buNpeiadWd82VxtjgPvoGcoRutc3j2Nu6wHNgxkIkqdBW YpXtsql8z0v6B5UM1N/XMPUdZ+HiZ9WoYIAMyAN7Nogld0k4WR4b0qmEW3gihjzXvLlt rGxenB7Pof6NqcF9rrbN6olzW6/MUZNQP/EA1n4AYKKND2xdCdKG2Kq9UtrC7lPlFDtT tZPnZmxaeAzXJVtdjiEQu1u0mzcySl7jJEZxGw6svm2rf1Rsdy69EP0sn5rS8tDx+1/J OTnrdUSrzf6ye0uEAJILUDvQoTxLo6qHy6pjaZtqoFWAUGLC8h3uH9lrTNC9/p5TllkG 5QrA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1773035687; x=1773640487; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=+eXVlNI+VPppaY/morooabCwuSYEtf9ABnZ29jfqnh4=; b=m0zOh7wI+2BeqFDe7RI3XEYgy/qh0sqBbYzMjbupPIZma1U6la049X/XKlez6eI1Gf 2h2kys9bhj45SqllkVF9Tqr5YBQDsb5Q9Lz6e8Gv9Zv0/WRonHvN/Jx63OrNLEAbiJCv iaUAfIzaCDG1mjv3EERbkG/waVX3c3CUZ+uCuX3nztaaZWBSVH4BnKqk0+TzFFO30dFW Uy0Q/sEAfowCEDg9CobrQtdyI7yVb/ILBu/90mih4mvEzwf4x8F9/I+VHp9eYVSdsyh7 t8fvsRq4RkvDCOrjYLLdYEgCfTo+EoURPw/9ykgjnOdBLyD2UqL/L3xkcos4TohZY6s3 c5xw== X-Forwarded-Encrypted: i=1; AJvYcCWavxjKdaVwN6MschdOc42O+b+1VhNTvApzqRZ9pP3vc7XLo1AXoZrHJhxQfupYPgG7GDLxORhCx4NlUVE=@vger.kernel.org X-Gm-Message-State: AOJu0YyE/MmnMk8gN3a2et4ooMn5nG/icbcoZNU5BH/59LoBHFNENg/u 0k96IagEGH0aK/cjjeW+hTGw5Ke9Zv8c8rQPf46H75RrM0idAiu0CiZU X-Gm-Gg: ATEYQzw9zAYWD4mxkNslHfM5S59LHNiiuoj+ZHFUGMrfFEp09YsOnohdm0Ah1pTw0v8 /okRGtda2SSzc1xFkwkpBpwrdwJX16YiaLtmixa3XfVNtabottoLhA3457osFNBSRmvHA/nbjxX xJlIG650pZte3iZJ/GbqCJZT3oqpV7/6k/jtQVoVdJqxuaOfGUQAXDHwbvdPIdaVzt3uyJRfSkj b9jq5aymb3q+X4toAyc4+hNqXhQ59FivCNIIcN1ecAIl3eOqFwk1LnhSrx+ttMdxqsOV7qTlxB1 nw29LOzZIgMN6fQBWahxB3+rx4FAF8BIuAVDnFws2+yhWOo77rdRutqztvVaoAQT0laZBFPXDSv DBJU1wqMHiIUQ3fq1I15BIrDA/VCwqNaGSZtDl66fRSjUQq7eXbltGzOUOOFjCxscgbRiLFivh2 TKE2A+LO2Kt+qc/fXpVXpEas6FjXSDz8MTJdKLL9eAh854GWZ6qO8uxCfrvSrU X-Received: by 2002:a05:6a20:cf8b:b0:38e:90ca:5a4b with SMTP id adf61e73a8af0-39859089f98mr9851848637.45.1773035686645; Sun, 08 Mar 2026 22:54:46 -0700 (PDT) Received: from zenbook ([159.196.5.243]) by smtp.gmail.com with ESMTPSA id 41be03b00d2f7-c739e170923sm7933716a12.17.2026.03.08.22.54.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 08 Mar 2026 22:54:46 -0700 (PDT) From: Wilfred Mallawa To: John Fastabend , Jakub Kicinski , Sabrina Dubroca , "David S . Miller" , Eric Dumazet , Paolo Abeni , Simon Horman , Jonathan Corbet , Shuah Khan Cc: netdev@vger.kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org, Alistair Francis , Damien Le'Moal , Wilfred Mallawa Subject: [RFC net-next 2/3] net/tls: add randomized zero padding socket option Date: Mon, 9 Mar 2026 15:48:37 +1000 Message-ID: <20260309054837.2299732-4-wilfred.opensource@gmail.com> X-Mailer: git-send-email 2.53.0 In-Reply-To: <20260309054837.2299732-2-wilfred.opensource@gmail.com> References: <20260309054837.2299732-2-wilfred.opensource@gmail.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Wilfred Mallawa Currently, for TLS 1.3, ktls does not support record zero padding [1]. Record zero padding is used to allow the sender to hide the size of the traffic patterns from an observer. TLS is susceptible to a variety of traff= ic analysis attacks based on observing the length and timing of encrypted packets [2]. Upcoming Western Digital NVMe-TCP hardware controllers implement TLS 1.3. Which from a security perspective, can benefit from havi= ng record zero padding enabled to mitigate against traffic analysis attacks [2]. Add a new TLS_TX_RANDOM_PAD ktls socket option that allows userspace to enable and specify an upperbound for randomized record zero padding in TLS 1.3. When this value is set and non-zero, ktls will append a randomized amount of [0, min(record_room, upper_bound)] bytes to records that are end-of-record (EOR) and aren't full. This can be set back to zero to disable appending zero padding. By default, no record zero padding is ad= ded. The number of zero padding bytes is randomised primarilly to reduce some of the throughput overhead of using a fixed zero padding amount up to the record size limit. [1] https://datatracker.ietf.org/doc/html/rfc8446#section-5.4l [2] https://datatracker.ietf.org/doc/html/rfc8446#appendix-E.3 Signed-off-by: Wilfred Mallawa --- Documentation/networking/tls.rst | 21 ++++++++++ include/uapi/linux/tls.h | 2 + net/tls/tls_main.c | 70 ++++++++++++++++++++++++++++++++ 3 files changed, 93 insertions(+) diff --git a/Documentation/networking/tls.rst b/Documentation/networking/tl= s.rst index 980c442d7161..e112a68a9bfb 100644 --- a/Documentation/networking/tls.rst +++ b/Documentation/networking/tls.rst @@ -300,6 +300,27 @@ extra byte used by the ContentType field. =20 [1] https://datatracker.ietf.org/doc/html/rfc8449 =20 +TLS_TX_RANDOM_PAD +~~~~~~~~~~~~~~~~~ + +Enable and set the limit for randomized zero padding [1] of outgoing +TLS records. + +When enabled, TLS records that are not full and are end of record (EOR) +will be padded with a randomly chosen amount of zero padding up to the rem= aining +record capacity or the limit provided by this option (smaller of the two). +Randomized zero padding can reduce information leakage via observable TLS +record lengths and mitigates traffic analysis based on message size. + +Padding never exceeds the protocol maximum record size and full-sized reco= rds +are unchanged. + +This increases bandwidth usage and may add CPU overhead due to padding +generation and larger encryption operations. For workloads with small reco= rds, +the bandwidth overhead may be significant. + +[1] https://datatracker.ietf.org/doc/html/rfc8446#section-5.4 + Statistics =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20 diff --git a/include/uapi/linux/tls.h b/include/uapi/linux/tls.h index b8b9c42f848c..42a318cb5eb8 100644 --- a/include/uapi/linux/tls.h +++ b/include/uapi/linux/tls.h @@ -42,6 +42,7 @@ #define TLS_TX_ZEROCOPY_RO 3 /* TX zerocopy (only sendfile now) */ #define TLS_RX_EXPECT_NO_PAD 4 /* Attempt opportunistic zero-copy */ #define TLS_TX_MAX_PAYLOAD_LEN 5 /* Maximum plaintext size */ +#define TLS_TX_RANDOM_PAD 6 /* TLS TX randomized record zero padding */ =20 /* Supported versions */ #define TLS_VERSION_MINOR(ver) ((ver) & 0xFF) @@ -196,6 +197,7 @@ enum { TLS_INFO_ZC_RO_TX, TLS_INFO_RX_NO_PAD, TLS_INFO_TX_MAX_PAYLOAD_LEN, + TLS_INFO_TX_RANDOM_PAD, __TLS_INFO_MAX, }; #define TLS_INFO_MAX (__TLS_INFO_MAX - 1) diff --git a/net/tls/tls_main.c b/net/tls/tls_main.c index b0702effbc26..62c525afbc14 100644 --- a/net/tls/tls_main.c +++ b/net/tls/tls_main.c @@ -563,6 +563,30 @@ static int do_tls_getsockopt_tx_payload_len(struct soc= k *sk, char __user *optval return 0; } =20 +static int do_tls_getsockopt_tx_random_pad(struct sock *sk, char __user *o= ptval, + int __user *optlen) +{ + struct tls_context *ctx =3D tls_get_ctx(sk); + u16 pad_limit =3D ctx->tx_record_zero_pad; + int len; + + if (ctx->prot_info.version !=3D TLS_1_3_VERSION) + return -EOPNOTSUPP; + + if (get_user(len, optlen)) + return -EFAULT; + + if (len < sizeof(pad_limit)) + return -EINVAL; + + if (put_user(sizeof(pad_limit), optlen)) + return -EFAULT; + + if (copy_to_user(optval, &pad_limit, sizeof(pad_limit))) + return -EFAULT; + + return 0; +} static int do_tls_getsockopt(struct sock *sk, int optname, char __user *optval, int __user *optlen) { @@ -585,6 +609,9 @@ static int do_tls_getsockopt(struct sock *sk, int optna= me, case TLS_TX_MAX_PAYLOAD_LEN: rc =3D do_tls_getsockopt_tx_payload_len(sk, optval, optlen); break; + case TLS_TX_RANDOM_PAD: + rc =3D do_tls_getsockopt_tx_random_pad(sk, optval, optlen); + break; default: rc =3D -ENOPROTOOPT; break; @@ -860,6 +887,33 @@ static int do_tls_setsockopt_tx_payload_len(struct soc= k *sk, sockptr_t optval, return 0; } =20 +static int do_tls_setsockopt_tx_random_pad(struct sock *sk, sockptr_t optv= al, + unsigned int optlen) +{ + struct tls_context *ctx =3D tls_get_ctx(sk); + struct tls_sw_context_tx *sw_ctx =3D tls_sw_ctx_tx(ctx); + u16 value; + + if (ctx->prot_info.version !=3D TLS_1_3_VERSION) + return -EOPNOTSUPP; + + if (sw_ctx && sw_ctx->open_rec) + return -EBUSY; + + if (sockptr_is_null(optval) || optlen !=3D sizeof(value)) + return -EINVAL; + + if (copy_from_sockptr(&value, optval, sizeof(value))) + return -EFAULT; + + if (value >=3D ctx->tx_max_payload_len) + return -EINVAL; + + ctx->tx_record_zero_pad =3D value; + + return 0; +} + static int do_tls_setsockopt(struct sock *sk, int optname, sockptr_t optva= l, unsigned int optlen) { @@ -886,6 +940,11 @@ static int do_tls_setsockopt(struct sock *sk, int optn= ame, sockptr_t optval, rc =3D do_tls_setsockopt_tx_payload_len(sk, optval, optlen); release_sock(sk); break; + case TLS_TX_RANDOM_PAD: + lock_sock(sk); + rc =3D do_tls_setsockopt_tx_random_pad(sk, optval, optlen); + release_sock(sk); + break; default: rc =3D -ENOPROTOOPT; break; @@ -1173,6 +1232,13 @@ static int tls_get_info(struct sock *sk, struct sk_b= uff *skb, bool net_admin) if (err) goto nla_failure; =20 + if (version !=3D TLS_1_3_VERSION) { + err =3D nla_put_u16(skb, TLS_INFO_TX_RANDOM_PAD, + ctx->tx_record_zero_pad); + if (err) + goto nla_failure; + } + rcu_read_unlock(); nla_nest_end(skb, start); return 0; @@ -1185,6 +1251,7 @@ static int tls_get_info(struct sock *sk, struct sk_bu= ff *skb, bool net_admin) =20 static size_t tls_get_info_size(const struct sock *sk, bool net_admin) { + struct tls_context *ctx =3D tls_get_ctx(sk); size_t size =3D 0; =20 size +=3D nla_total_size(0) + /* INET_ULP_INFO_TLS */ @@ -1197,6 +1264,9 @@ static size_t tls_get_info_size(const struct sock *sk= , bool net_admin) nla_total_size(sizeof(u16)) + /* TLS_INFO_TX_MAX_PAYLOAD_LEN */ 0; =20 + if (ctx->prot_info.version =3D=3D TLS_1_3_VERSION) + size +=3D nla_total_size(sizeof(u16)); /* TLS_INFO_TX_RANDOM_PAD */ + return size; } =20 --=20 2.53.0