From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pg1-f170.google.com (mail-pg1-f170.google.com [209.85.215.170]) (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 4B90F1E834E for ; Mon, 9 Mar 2026 05:54:34 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.215.170 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773035676; cv=none; b=UW8SwhoGcbssG4zhm8Lm2b8USolU++79BbRJABeYsb3FCoPZ+v08FNxP/IcPWNsckQejLFoyasRU+I8MKOYFqHbC39Y/qDAKu1ekDX+skzm2LQ0ThBPqN/g2wKGjaSmsEW2T7SCDljVww/W9Dp2n6vtTC6R9/IxIMk8K11tNqhQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773035676; c=relaxed/simple; bh=yhRXDuYeW+cftAqeXj832wG18URrEw+/ciyn8otv1bs=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=I78UcatEX+QtEwosQBi9kb+VT1r1ChXCQA0ekfKrSH4F4lNjLXLdEVVX3EvH25L1xLw/roT4TOGGp2sDONRDVVlUh5Jd6270yagqwo+dyqR8g8eEJPqT0dlppV6CLKXxoum1Mo9GW/bDAciLnYDm71ioPbcFWUG05apZA9kos6A= 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=cV6Zl/kq; arc=none smtp.client-ip=209.85.215.170 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="cV6Zl/kq" Received: by mail-pg1-f170.google.com with SMTP id 41be03b00d2f7-c06cb8004e8so4344425a12.0 for ; Sun, 08 Mar 2026 22:54:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1773035674; x=1773640474; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=pQy7F8PJ6uvy5F2yRW0mdhvL40ZL+dX8MEO00CpDqi0=; b=cV6Zl/kqBNxv607ftvljCrRKjOqcbnx0iTV0DaBN+eXRUoTGEGfoAT3LlezY2XsY13 RisOZV4Kn7yZqBC8sxM9rcXjoY/18AtzqBboyHhQ1Rv0x/mTfVpuNj72cLMw+gdGamv2 unI+FZ3nF+Ls0H53ywqXupejOUsIDfxUSi5epsMQ6pXIWGy7cZaY0/pB6Q13I9DTy+Pm 6fYz0ORxpJOZjrYX7ywp0QFEwwWnsQQGdbBvrrvv4cMw4gAdIHbE4yVy1DHASb02oS65 mc/EbhJGwDPyhDnLwvTltSf6Ew0cHf1qkF9WQJYZ+Y9eaSSRkP2+yyJl9RBBopo49QrD lRaQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1773035674; x=1773640474; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=pQy7F8PJ6uvy5F2yRW0mdhvL40ZL+dX8MEO00CpDqi0=; b=lYrtyP5KXXaflRZPPTRw3FqC+RPnvsYBVGedw9/+6dF8/gxZaD1w5Vw2PVSOfJHEqF VksH97rZo4QckZqVRitqH2PC7bI6D9Q7uJqQvlJdZw92VWk8/FqwbmW3TBpP3ao/UHus bwViiFxYrkfKQhV9TMab6dZhfqOdL3uuLUI71apUQj6c2/7FEG5dPnnEBI5KHLlXTRnl 8s42hIhKG6BJSEKU+dML49c7RV3oompg4thyat7bShSubwRUlxHfPMlaZQouk/+85O4Q 1CQV76QM6F/3aZJQgPnPlyCn9lB7DWIHoYWuqHx47B1eiYdFIx1DHvpWcZYD684aYYwY 6Q/A== X-Forwarded-Encrypted: i=1; AJvYcCUdvwP/+CKl9MHjrZIHb13yiLt1Ksck4ZXDLCoehAfLXbbLDhrMB9c31c0Kg6FBDOGuKvfiLtkFDnV9y5U=@vger.kernel.org X-Gm-Message-State: AOJu0YwxjMZH+Pz6rqYXBd+N+0FjCpESjgp1mksIAf/Cjd0JL8lHi7p/ 0isFRCW5l6JTUHPZS1icIfMgWrNpjw+ZXE7H9qg1NUxxwL+NKsf8y2w7 X-Gm-Gg: ATEYQzyRYqscirT+r6K+5nPQtI3/Znglej85xCa43nzsfap1VGFJBDypCEkOpf2KUuI w8f+MF09Qho7MiIV8BEhvU4daiuy3zX286mqilP6h+ViOFoshT6h3UyjXqCHO7dc7jVgWgu3acF Nm+YL3DsRRRrr0SAVrcwHf7TS6UFTMjeBuJ6EZV3In4mY6AIFbS9E+hSANrp2mVPJWXLi73q4RL qw0viGB7KQDqalMdZstP2XX/EtlApFjp0bGUsaVm6jofut1+r+9UBOdO662H5esGLtTmy5Y7otc V0vxvLcTp++hY5LRlcPmg12iC/8o+NsBNTgM3ejLQrkzrkMfPNqU+x0GuI4wecuZAkeb3SELAsf +tgBuPuWXdXzPpMvgXEQ7CAqq2uFx/yxlqiZO5o8t5eVnAesz7TL2fZJELrArxj9INldFuXIAAB Lz+4i0OeLYSO1tMiUQ6x28zEyaliSsYc+froUtf1TMFhElMr424vaRaFshjq2K X-Received: by 2002:a05:6a20:d527:b0:395:b6ff:fe57 with SMTP id adf61e73a8af0-398590d3b1dmr9399688637.63.1773035673636; Sun, 08 Mar 2026 22:54:33 -0700 (PDT) Received: from zenbook ([159.196.5.243]) by smtp.gmail.com with ESMTPSA id 41be03b00d2f7-c739e170923sm7933716a12.17.2026.03.08.22.54.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 08 Mar 2026 22:54:33 -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 0/3] tls_sw: add tx record zero padding Date: Mon, 9 Mar 2026 15:48:35 +1000 Message-ID: <20260309054837.2299732-2-wilfred.opensource@gmail.com> X-Mailer: git-send-email 2.53.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit 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 traffic 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 having record zero padding enabled to mitigate against traffic analysis attacks [2]. Thus, for TX, this series adds support to adding randomized number of zero padding bytes to end-of-record (EOR) records that are not full. This feature is disabled by default and can be enabled by the new TLS_TX_RANDOM_PAD socket option. TLS_TX_RANDOM_PAD allows users to set an upper bound for the number of bytes to be used in zero padding, and can be set back to 0 to disable zero padding altogher. The number of zero padding bytes to append is determined by the remaining record room and the user specified upper bound (minimum of the two). That is rand([0, min(record_room, upper_bound)]). Also a selftest is added to test the usage of TLS_TX_RANDOM_PAD. However, it does not test for zero padding bytes as that is stripped in the ktls RX path. Additional testing done on a linux NVMe Target with TLS by issuing an FIO workload to the target and asserting that the target kernel sees and strips the zero padding attached. [1] https://datatracker.ietf.org/doc/html/rfc8446#section-5.4l [2] https://datatracker.ietf.org/doc/html/rfc8446#appendix-E.3 Wilfred Mallawa (3): net/tls_sw: support randomized zero padding net/tls: add randomized zero padding socket option selftest: tls: add tls record zero pad test Documentation/networking/tls.rst | 21 +++++++++ include/net/tls.h | 1 + include/uapi/linux/tls.h | 2 + net/tls/tls.h | 6 ++- net/tls/tls_main.c | 72 +++++++++++++++++++++++++++++++ net/tls/tls_sw.c | 58 ++++++++++++++++++++----- tools/testing/selftests/net/tls.c | 45 +++++++++++++++++++ 7 files changed, 194 insertions(+), 11 deletions(-) -- 2.53.0