From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Biggers Subject: Re: [PATCH] crypto: x86/aes - Don't use %rbp as temporary register Date: Wed, 17 May 2017 15:21:41 -0700 Message-ID: <20170517222141.GA60476@gmail.com> References: <20170517040308.406-1-ebiggers3@gmail.com> <20170517204427.lwvzonoa26paoitk@treble> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: linux-crypto@vger.kernel.org, Herbert Xu , "David S . Miller" , x86@kernel.org, linux-kernel@vger.kernel.org, Eric Biggers To: Josh Poimboeuf Return-path: Received: from mail-pg0-f66.google.com ([74.125.83.66]:36695 "EHLO mail-pg0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754464AbdEQWVp (ORCPT ); Wed, 17 May 2017 18:21:45 -0400 Content-Disposition: inline In-Reply-To: <20170517204427.lwvzonoa26paoitk@treble> Sender: linux-crypto-owner@vger.kernel.org List-ID: On Wed, May 17, 2017 at 03:44:27PM -0500, Josh Poimboeuf wrote: > On Tue, May 16, 2017 at 09:03:08PM -0700, Eric Biggers wrote: > > From: Eric Biggers > > > > When using the "aes-asm" implementation of AES (*not* the AES-NI > > implementation) on an x86_64, v4.12-rc1 kernel with lockdep enabled, the > > following warning was reported, along with a long unwinder dump: > > > > WARNING: kernel stack regs at ffffc90000643558 in kworker/u4:2:155 has bad 'bp' value 000000000000001c > > > > The problem is that aes_enc_block() and aes_dec_block() use %rbp as a > > temporary register, which breaks stack traces if an interrupt occurs. > > > > Fix this by replacing %rbp with %r9, which was being used to hold the > > saved value of %rbp. This required rearranging the AES round macro > > slightly since %r9d cannot be used as the target of a move from %ah-%dh. > > > > Performance is essentially unchanged --- actually about 0.2% faster than > > before. Interestingly, I also measured aes-generic as being nearly 7% > > faster than aes-asm, so perhaps aes-asm has outlived its usefulness... > > > > Signed-off-by: Eric Biggers > > Reviewed-by: Josh Poimboeuf > Hmm, it looks like a number of other algorithms in arch/x86/crypto/ use %rbp (or %ebp), e.g. blowfish, camellia, cast5, and aes-i586. Presumably they have the same problem. I'm a little confused: do these all need to be fixed, and when/why did this start being considered broken? Eric