From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f52.google.com (mail-wm1-f52.google.com [209.85.128.52]) (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 6C91832B12A for ; Tue, 14 Jul 2026 07:58:10 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.52 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784015892; cv=none; b=FV0A9kSw5buJimF1pfvrYMIo2Q5h6J7StrAAXUqgLcY8SQZJ/WJ3cRVg+4cLCpEiWmVdORdZMlZkilDEqrwYanAQ68U7JoRMVt7iaL+EOnZ30gwP9FMh4kge59uMZCkg6dl0J2kfP/ORqx1zWrVMh0LUrROBpY8ruXtzHJ4Ey2k= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784015892; c=relaxed/simple; bh=XTWkmfzt6ioT+1/A2ObsntoO/EkHl+ez7DSgh7Aza20=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=AJ/FcNyiK9LCGBbpvD4cVxc8SOowjC9b5hDcTZ2GNDM75vL188btzjgPs95DhN1Y1uLZ41AqydF28v1SK0cTWGxaLRuGIwozoDqbB56g+1JUk9+9a3ZCAQkQTlQJi92L5G4/FyYCs0l2RbLh1FNYS7l0+GxWUEUHgwCvY8qIPgI= 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=W6HxbwsP; arc=none smtp.client-ip=209.85.128.52 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="W6HxbwsP" Received: by mail-wm1-f52.google.com with SMTP id 5b1f17b1804b1-493bb510ce4so28284995e9.1 for ; Tue, 14 Jul 2026 00:58:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1784015889; x=1784620689; darn=vger.kernel.org; h=content-transfer-encoding:content-type:mime-version:references :in-reply-to:message-id:subject:cc:to:from:date:from:to:cc:subject :date:message-id:reply-to:content-type; bh=O4Va9/3fzJvfM0bModCoGUiBD/cgXboTZMAPr8id/xE=; b=W6HxbwsPIIbivKodrovJjANef+lzT0KsOLNattSdQB146cJt5IHcCHT7JCmkGAv2Re BUcRNj6SregR2/3V5ldQNMe1fxottrjDO1poMDu1EwlPcmJEQ/TjZucqtuYp9CoACTdD E0A0UZQRqzpvBp8hpmm19BaShEnUC3pqk1cHwsePUfGShUcQcakoG9se95AvjUiTiDs2 owUqdKheFUBiKUoQkayACjR53DJFjhMt6bGDZ4LoEYO5PYtn48L3LY3MgfFr4I5WQlsX Rc/UdLWJXNqMvzm0mh7M431oTdP8pr16GYZSoDotjOiYH0cCRQDULLXaySARk+rVPI+m 7sGg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1784015889; x=1784620689; h=content-transfer-encoding:content-type:mime-version:references :in-reply-to:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=O4Va9/3fzJvfM0bModCoGUiBD/cgXboTZMAPr8id/xE=; b=D7BfcHzT/IPHrEH/NP6On79QJxGkxRA0YdsoOzxWr9iuf4bZYBKQUQpbsMtv7ZXVVN dGo6Dj/0dSubcbLP6rwoeYmPshRSVYcYUBfrJlDz0R8xlJjMjyKO+M+2ipwzC4h8s5O8 fGRV+vyEmB2lAxbPDFEVm8mo0rvgY1mRXZ7k47WzI6vdAGbPHuW/sbXKpNK4jMd25Kmn MaDF/HJVuJGK0CViTKUeZH0BAzTXz479VKfdpi/et13jwHICdGKzEzG2qVcYKh0yvUKB yGi+mOZok6JkbHkwvRY4GI1MWxDWAw1M56thBhAZHh6BnKQQAR6atgI8PUdCj18AEmit D23w== X-Forwarded-Encrypted: i=1; AHgh+RpqRZ2TRIdmXJJxPXQ05+SFFYobA8m47uT8SS+DCPWypojo/BFGnG72lAP+Xg/RXXXqIM02HHju7LpMIDw=@vger.kernel.org X-Gm-Message-State: AOJu0YxFl1bJRD8OYXPtzJqCR5+zK5ZXtpO90ZklUAfaLIsNDCFQyqN6 Sze35ec/1evmlHrwdykOGh5iQsRNAdJoqIB00oL1HEdg24rvCYXF6Yhd X-Gm-Gg: AfdE7cn/p7oXJgC/XOw+1EcRXJAAfwkrNyOeJboMNFqWctpj5/3SayJ0VYshE5KUF27 sFJ58VibtdP76uB8rC9lySVt/GHA+oFOOeH5tpujOsbS9kWzcUTaVbs2+3t0/KBXK9FSVYcDOqc mkW1yUzAks0pTZDYIcu+fwgiDhrAVzkNHXiCYopnpdeAT5aMhg43OESTXqHeI5A314qLUBPa2Je D9uGQiM9Ofc1mSPTdogW8hU+bEjxz/iyFz+YgNg4wSIWbZCUukOuIymD/0ymEAodUmpzBAQkN6j +ryQuWZVl4vBC2peoqA2zxnlBLWPw0KWY0fsKcVCiGVKUSdBnGm1XU/G62falX03NeMA32++vPG t5XJfK1dxZQcSs12EK7ywmlBGFEMtp/GMFiF5zJoV0iz9eo4/UVGymWqSvnHkMwD+Cmfo08zR5n HKEhZ4yNwhZ5xDN8To0tL9GDUz7cdnpFB3y33cW7Jzxh5Q3F1Sqw== X-Received: by 2002:a05:600c:1d9a:b0:493:c8f7:3631 with SMTP id 5b1f17b1804b1-495389bcc3fmr12972915e9.22.1784015888603; Tue, 14 Jul 2026 00:58:08 -0700 (PDT) Received: from pumpkin (82-69-66-36.dsl.in-addr.zen.co.uk. [82.69.66.36]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4950a2f635dsm58640505e9.12.2026.07.14.00.58.08 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 14 Jul 2026 00:58:08 -0700 (PDT) Date: Tue, 14 Jul 2026 08:58:04 +0100 From: David Laight To: Thomas Huth Cc: Eric Biggers , linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 04/33] lib/crypto: aes: Add CTR and XCTR support Message-ID: <20260714085804.189692f8@pumpkin> In-Reply-To: <34db35e3-7d6e-4ce2-bd3c-cbe74b321bc4@redhat.com> References: <20260707053503.209874-1-ebiggers@kernel.org> <20260707053503.209874-5-ebiggers@kernel.org> <40932e40-a909-4b95-b739-c4727c1cc153@redhat.com> <20260713235439.GB24654@quark> <34db35e3-7d6e-4ce2-bd3c-cbe74b321bc4@redhat.com> X-Mailer: Claws Mail 4.1.1 (GTK 3.24.38; arm-unknown-linux-gnueabihf) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Tue, 14 Jul 2026 06:53:32 +0200 Thomas Huth wrote: > On 14/07/2026 01.54, Eric Biggers wrote: > > On Mon, Jul 13, 2026 at 10:39:53AM +0200, Thomas Huth wrote: > >>> diff --git a/Documentation/crypto/libcrypto-unauth-encryption.rst b/Documentation/crypto/libcrypto-unauth-encryption.rst > >>> index fb8106034089..6aca01d715da 100644 > >>> --- a/Documentation/crypto/libcrypto-unauth-encryption.rst > >>> +++ b/Documentation/crypto/libcrypto-unauth-encryption.rst > >>> @@ -27,6 +27,13 @@ Support for AES in the CBC and CBC-CTS modes of operation. > >>> .. kernel-doc:: include/crypto/aes-cbc.h > >>> +AES-CTR and AES-XCTR > >>> +-------------------- > >>> + > >>> +Support for AES in the CTR and XCTR modes of operation. > >> > >> I guess you already have this on your radar, but just in case: It would be > >> nice to turn this into a full sentence, too. > > > > Yes, I'm making all of them full sentences. > > > >>> +/** > >>> + * aes_ctr() - AES-CTR en/decryption > >>> + * @dst: The destination buffer. Can be in-place or out-of-place. For other > >>> + * overlaps the behavior is unspecified. > >>> + * @src: The source data > >>> + * @len: Number of bytes to en/decrypt > >>> + * @ctr: The counter. It will be incremented by ceil(@len / AES_BLOCK_SIZE). > >>> + * @key: The key > >>> + * > >>> + * This implements AES in counter mode with a 128-bit big endian counter. > >>> + * > >>> + * This supports incremental en/decryption. The length of each non-final chunk > >>> + * must be a multiple of AES_BLOCK_SIZE, and the updated @ctr must be passed in > >>> + * each time. > >> > >> Maybe add some wording that ctr ideally should not be 0 for the first call, > >> i.e. a "nonce" value? > > > > It depends on the usage. If a distinct key is used for each message for > > example, always starting at 0 is perfectly fine. > > > > I'm not sure how far we should go to document the proper use of each > > algorithm. Really the AES-CTR support is just for internal use by > > AES-GCM and AES-CCM, and a few odd users that implement specific other > > protocols that need AES-CTR. It's not intended to be a place to go to > > receive an introduction to CTR mode. > > > >>> +static __always_inline void inc_be128_ctr(u8 ctr[AES_BLOCK_SIZE]) > >>> +{ > >>> + /* Casts to u8 are needed because of the implicit integer promotion. */ > >>> + if (((u8)++ctr[AES_BLOCK_SIZE - 1]) != 0) > >>> + return; > >> > >> Why do you handle the first value separately here? The code could be > >> simplified to start with "int i = AES_BLOCK_SIZE -1" in the for-loop > >> instead? > > > > Just a trick to optimize performance by unrolling the first iteration, > > since 255 times out of 256 the first iteration is enough. > Ok, but then maybe add a comment here. Otherwise people will wonder why it > has been done like this when reading the code later. > > FWIW, I doubt that this really makes a big difference here. Looking at a > function that contains your code, the disassembly currently looks like this > (with -O2): > > 0000000000000000 : > 0: 80 47 0f 01 addb $0x1,0xf(%rdi) > 4: 48 8d 57 0e lea 0xe(%rdi),%rdx Those two run in the same clock. > 8: 74 0a je 14 Depends on the 'addb', hopefully/likely predicted non-taken. > a: c3 ret Predicted taken using the RSB. Execution continues speculatively after the call even before the memory read for 0xf(%rdi) has completed. > b: 0f 1f 44 00 00 nopl 0x0(%rax,%rax,1) > 10: 48 83 ea 01 sub $0x1,%rdx > 14: 80 02 01 addb $0x1,(%rdx) > 17: 75 05 jne 1e > 19: 48 39 d7 cmp %rdx,%rdi > 1c: 75 f2 jne 10 > 1e: c3 ret > > So that's 3 assembly instructions 'til you reach the "ret". > > When you drop the optimization, it looks like this: > > 0000000000000000 : > 0: 48 8d 57 0f lea 0xf(%rdi),%rdx > 4: eb 0e jmp 14 > 6: 66 2e 0f 1f 84 00 00 cs nopw 0x0(%rax,%rax,1) > d: 00 00 00 > 10: 48 83 ea 01 sub $0x1,%rdx > 14: 80 02 01 addb $0x1,(%rdx) That depends on the 'sub' > 17: 75 05 jne 1e That is likely predicted not taken - so you get a misprediction penalty > 19: 48 39 d7 cmp %rdx,%rdi > 1c: 75 f2 jne 10 > 1e: c3 ret > > That's 4 assembly instructions 'til you reach the "ret". Not such a big > difference...? There is an extra 'jmp' - that will cost in the fetch-decode part. The alignment pad (not there in the kernel) might also force another i-cache line be accessed. The first conditional branch is mispredicted - say 20 clocks. In any case the instruction count doesn't really matter. What matters is the length of the register dependency chain and how the branches get predicted. I've gone back and annotated the asm. > > And with -O3, both variants end up with the same code. No one sane would compile the kernel (or much else) with -O3. It bloats things too much. gcc isn't that good at optimising loops for modern cpu. -- David > > Thomas > >