crypto: x86 - exit fpu context earlier in ECB/CBC macros

Message ID IBooTlGWpNE7pOelt0gm21bxW7wBILNYJ1HaoPbbfdEEMwz0Pp92vpd_OUlhNFNAitFThTi27P6q6NvcYMKm-y7tjwiF9YbImWjhgC3UDMk=@n8pjl.ca
State New
Headers
Series crypto: x86 - exit fpu context earlier in ECB/CBC macros |

Commit Message

Peter Lafreniere Jan. 16, 2023, 2:59 p.m. UTC
  Currently the ecb/cbc macros hold fpu context unnecessarily when using 
scalar cipher routines (e.g. when handling odd sizes of blocks per walk).

Change the macros to drop fpu context as soon as the fpu is out of use.

No performance impact found (on Intel Haswell).

Signed-off-by: Peter Lafreniere <peter@n8pjl.ca>
---
 arch/x86/crypto/ecb_cbc_helpers.h | 19 +++++++++++++++----
 1 file changed, 15 insertions(+), 4 deletions(-)
  

Comments

Ard Biesheuvel Jan. 16, 2023, 3:09 p.m. UTC | #1
On Mon, 16 Jan 2023 at 16:00, Peter Lafreniere <peter@n8pjl.ca> wrote:

Please don't send encrypted emails to the mailing list. Plaintext
only, with the patch in the message body (not as an attachment).
Please use git send-email if you have trouble configuring your email
client.
  
Peter Lafreniere Jan. 16, 2023, 3:20 p.m. UTC | #2
> Please don't send encrypted emails to the mailing list. Plaintext
> only, with the patch in the message body (not as an attachment).
> Please use git send-email if you have trouble configuring your email
> client.

My apologies. I was having difficulties configuring git send-email,
but now I believe that I have the issues resolved. Future patches will
be properly formatted.

- Peter
  
Conor Dooley Jan. 16, 2023, 3:32 p.m. UTC | #3
On Mon, Jan 16, 2023 at 03:20:59PM +0000, Peter Lafreniere wrote:
> > Please don't send encrypted emails to the mailing list. Plaintext
> > only, with the patch in the message body (not as an attachment).
> > Please use git send-email if you have trouble configuring your email
> > client.


> My apologies. I was having difficulties configuring git send-email,
> but now I believe that I have the issues resolved. Future patches will
> be properly formatted.

It landed okay on lore:
https://lore.kernel.org/linux-crypto/IBooTlGWpNE7pOelt0gm21bxW7wBILNYJ1HaoPbbfdEEMwz0Pp92vpd_OUlhNFNAitFThTi27P6q6NvcYMKm-y7tjwiF9YbImWjhgC3UDMk=@n8pjl.ca/#t

I've seen enough of these now to know where this is going, I'd bet that
you're a protonmail user...
  
Peter Lafreniere Jan. 16, 2023, 3:40 p.m. UTC | #4
> > My apologies. I was having difficulties configuring git send-email,
> > but now I believe that I have the issues resolved. Future patches will
> > be properly formatted.
> 
> 
> It landed okay on lore:
> https://lore.kernel.org/linux-crypto/IBooTlGWpNE7pOelt0gm21bxW7wBILNYJ1HaoPbbfdEEMwz0Pp92vpd_OUlhNFNAitFThTi27P6q6NvcYMKm-y7tjwiF9YbImWjhgC3UDMk=@n8pjl.ca/#t

Yup, that's why I'm not resending it.

> 
> I've seen enough of these now to know where this is going, I'd bet that
> you're a protonmail user...

You would be quite correct. They do like making your life difficult when
it comes to using smtp.

Anyway, the patch landed fine on lore and patchwork and I've (finally)
configured git-send-email properly, so I think that this should be all 
good now.

Again, sorry for the issues,
Peter Lafreniere
  
Conor Dooley Jan. 16, 2023, 4:27 p.m. UTC | #5
On 16/01/2023 15:40, Peter Lafreniere wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> 
>>> My apologies. I was having difficulties configuring git send-email,
>>> but now I believe that I have the issues resolved. Future patches will
>>> be properly formatted.
>>
>>
>> It landed okay on lore:
>> https://lore.kernel.org/linux-crypto/IBooTlGWpNE7pOelt0gm21bxW7wBILNYJ1HaoPbbfdEEMwz0Pp92vpd_OUlhNFNAitFThTi27P6q6NvcYMKm-y7tjwiF9YbImWjhgC3UDMk=@n8pjl.ca/#t
> 
> Yup, that's why I'm not resending it.
> 
>>
>> I've seen enough of these now to know where this is going, I'd bet that
>> you're a protonmail user...
> 
> You would be quite correct. They do like making your life difficult when
> it comes to using smtp.
> 
> Anyway, the patch landed fine on lore and patchwork and I've (finally)
> configured git-send-email properly, so I think that this should be all
> good now.

Unfortunately that's the most annoying part. Proton encrypts the copies
to specific recipients only... See:
https://lore.kernel.org/all/20221231152320.1340874-1-conor@kernel.org/

Thanks,
Conor.
  
Ard Biesheuvel Jan. 16, 2023, 4:33 p.m. UTC | #6
On Mon, 16 Jan 2023 at 16:32, Conor Dooley <conor.dooley@microchip.com> wrote:
>
> On Mon, Jan 16, 2023 at 03:20:59PM +0000, Peter Lafreniere wrote:
> > > Please don't send encrypted emails to the mailing list. Plaintext
> > > only, with the patch in the message body (not as an attachment).
> > > Please use git send-email if you have trouble configuring your email
> > > client.
>
>
> > My apologies. I was having difficulties configuring git send-email,
> > but now I believe that I have the issues resolved. Future patches will
> > be properly formatted.
>
> It landed okay on lore:
> https://lore.kernel.org/linux-crypto/IBooTlGWpNE7pOelt0gm21bxW7wBILNYJ1HaoPbbfdEEMwz0Pp92vpd_OUlhNFNAitFThTi27P6q6NvcYMKm-y7tjwiF9YbImWjhgC3UDMk=@n8pjl.ca/#t
>
> I've seen enough of these now to know where this is going, I'd bet that
> you're a protonmail user...
>

I am still receiving encrypted messages, and given that I am a direct
recipient, the mailing list server does not cc me then unencrypted
copies.

I am not going to reply to the patch until it lands in my inbox in
plaintext, sorry ...
  
Herbert Xu Jan. 27, 2023, 10:53 a.m. UTC | #7
Ard Biesheuvel <ardb@kernel.org> wrote:
>
> I am still receiving encrypted messages, and given that I am a direct
> recipient, the mailing list server does not cc me then unencrypted
> copies.
> 
> I am not going to reply to the patch until it lands in my inbox in
> plaintext, sorry ...

As Ard needs to review this patch, until this is resolved I won't
be applying this.

Thanks,
  
Ard Biesheuvel Jan. 27, 2023, 11:09 a.m. UTC | #8
On Fri, 27 Jan 2023 at 11:53, Herbert Xu <herbert@gondor.apana.org.au> wrote:
>
> Ard Biesheuvel <ardb@kernel.org> wrote:
> >
> > I am still receiving encrypted messages, and given that I am a direct
> > recipient, the mailing list server does not cc me then unencrypted
> > copies.
> >
> > I am not going to reply to the patch until it lands in my inbox in
> > plaintext, sorry ...
>
> As Ard needs to review this patch, until this is resolved I won't
> be applying this.
>

I've received the plaintext version in the mean time, it's on another thread.

So we can close this one.
  

Patch

diff --git a/arch/x86/crypto/ecb_cbc_helpers.h b/arch/x86/crypto/ecb_cbc_helpers.h
index eaa15c7b29d6..b83085e18ab0 100644
--- a/arch/x86/crypto/ecb_cbc_helpers.h
+++ b/arch/x86/crypto/ecb_cbc_helpers.h
@@ -14,12 +14,13 @@ 
 #define ECB_WALK_START(req, bsize, fpu_blocks) do {			\
 	void *ctx = crypto_skcipher_ctx(crypto_skcipher_reqtfm(req));	\
+	const int __fpu_blocks = (fpu_blocks);				\
 	const int __bsize = (bsize);					\
 	struct skcipher_walk walk;					\
 	int err = skcipher_walk_virt(&walk, (req), false);		\
 	while (walk.nbytes > 0) {					\
 		unsigned int nbytes = walk.nbytes;			\
-		bool do_fpu = (fpu_blocks) != -1 &&			\
-			      nbytes >= (fpu_blocks) * __bsize;		\
+		bool do_fpu = __fpu_blocks != -1 &&			\
+			      nbytes >= __fpu_blocks * __bsize;		\
 		const u8 *src = walk.src.virt.addr;			\
 		u8 *dst = walk.dst.virt.addr;				\
 		u8 __maybe_unused buf[(bsize)];				\
@@ -35,7 +36,12 @@ 
 } while (0)
 
 #define ECB_BLOCK(blocks, func) do {					\
-	while (nbytes >= (blocks) * __bsize) {				\
+	const int __blocks = (blocks);					\
+	if (do_fpu && __blocks < __fpu_blocks) {			\
+		kernel_fpu_end();					\
+		do_fpu = false;						\
+	}								\
+	while (nbytes >= __blocks * __bsize) {				\
 		(func)(ctx, dst, src);					\
 		ECB_WALK_ADVANCE(blocks);				\
 	}								\
@@ -53,7 +59,12 @@ 
 } while (0)
 
 #define CBC_DEC_BLOCK(blocks, func) do {				\
-	while (nbytes >= (blocks) * __bsize) {				\
+	const int __blocks = (blocks);					\
+	if (do_fpu && __blocks <  __fpu_blocks) {			\
+		kernel_fpu_end();					\
+		do_fpu = false;						\
+	}								\
+	while (nbytes >= __blocks * __bsize) {				\
 		const u8 *__iv = src + ((blocks) - 1) * __bsize;	\
 		if (dst == src)						\
 			__iv = memcpy(buf, __iv, __bsize);		\