Linux cryptographic layer development
 help / color / mirror / Atom feed
From: Gary R Hook <ghook@amd.com>
To: Arnd Bergmann <arnd@arndb.de>,
	"Lendacky, Thomas" <Thomas.Lendacky@amd.com>,
	"Hook, Gary" <Gary.Hook@amd.com>,
	Herbert Xu <herbert@gondor.apana.org.au>,
	"David S. Miller" <davem@davemloft.net>
Cc: "linux-crypto@vger.kernel.org" <linux-crypto@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 1/2] crypto: ccp - Reduce stack frame size with KASAN
Date: Tue, 28 Mar 2017 09:15:45 -0500	[thread overview]
Message-ID: <f04b2ede-f291-2ffa-d4a8-124d4af06199@amd.com> (raw)
In-Reply-To: <20170328095814.3734615-1-arnd@arndb.de>

On 03/28/2017 04:58 AM, Arnd Bergmann wrote:> The newly added AES GCM 
implementation uses one of the largest stack frames
> in the kernel, around 1KB on normal 64-bit kernels, and 1.6KB when
> CONFIG_KASAN
> is enabled:
>
> drivers/crypto/ccp/ccp-ops.c: In function 'ccp_run_aes_gcm_cmd':
> drivers/crypto/ccp/ccp-ops.c:851:1: error: the frame size of 1632 bytes
> is larger than 1536 bytes [-Werror=frame-larger-than=]
>
> This is problematic for multiple reasons:
>
>  - The crypto functions are often used in deep call chains, e.g. behind
>    mm, fs and dm layers, making it more likely to run into an actual stack
>    overflow
>
>  - Using this much stack space is an indicator that the code is not
>    written to be as efficient as it could be.

I'm not sure I agree that A -> B, but I will certainly look into this.

>  - While this goes unnoticed at the moment in mainline with the frame size
>    warning being disabled when KASAN is in use, I would like to enable
>    the warning again, and the current code is slightly above my arbitrary
>    pick for a limit of 1536 bytes (I already did patches for every other
>    driver exceeding this).

I've got my stack frame size (also) set to 1536, and would have paid 
more attention
had a warning occurred due to my code.

> A more drastic refactoring of the driver might be needed to reduce the
> stack usage more substantially, but this patch is fairly simple and
> at least addresses the third one of the problems I mentioned, reducing the
> stack size by about 150 bytes and bringing it below the warning limit
> I picked.

Again, I'll devote some time to this.

> diff --git a/drivers/crypto/ccp/ccp-dev.h b/drivers/crypto/ccp/ccp-dev.h
> index 3a45c2af2fbd..c5ea0796a891 100644
> --- a/drivers/crypto/ccp/ccp-dev.h
> +++ b/drivers/crypto/ccp/ccp-dev.h
> @@ -432,24 +432,24 @@ struct ccp_dma_info {
>          unsigned int offset;
>          unsigned int length;
>          enum dma_data_direction dir;
> -};
> +} __packed __aligned(4);

My gcc 4.8 doesn't understand __aligned(). Shouldn't we use
#pragma(4) here?


>  struct ccp_dm_workarea {
>          struct device *dev;
>          struct dma_pool *dma_pool;
> -       unsigned int length;
>
>          u8 *address;
>          struct ccp_dma_info dma;
> +       unsigned int length;
>  };
>
>  struct ccp_sg_workarea {
>          struct scatterlist *sg;
>          int nents;
> +       unsigned int dma_count;
>
>          struct scatterlist *dma_sg;
>          struct device *dma_dev;
> -       unsigned int dma_count;
>          enum dma_data_direction dma_dir;
>
>          unsigned int sg_used;

I'm okay with rearranging, but I'm going to submit an alternative patch.

  parent reply	other threads:[~2017-03-28 14:16 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-28  9:58 [PATCH 1/2] crypto: ccp - Reduce stack frame size with KASAN Arnd Bergmann
2017-03-28  9:58 ` [PATCH 2/2] crypto: ccp - Mark driver as little-endian only Arnd Bergmann
2017-03-28 14:08   ` Gary R Hook
2017-03-28 14:59     ` Arnd Bergmann
2017-03-28 15:26       ` Gary R Hook
2017-03-28 14:15 ` Gary R Hook [this message]
2017-03-28 15:03   ` [PATCH 1/2] crypto: ccp - Reduce stack frame size with KASAN Arnd Bergmann
2017-03-28 15:10   ` Arnd Bergmann
2017-03-28 15:28     ` Gary R Hook
2017-03-28 15:56     ` Gary R Hook

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=f04b2ede-f291-2ffa-d4a8-124d4af06199@amd.com \
    --to=ghook@amd.com \
    --cc=Gary.Hook@amd.com \
    --cc=Thomas.Lendacky@amd.com \
    --cc=arnd@arndb.de \
    --cc=davem@davemloft.net \
    --cc=herbert@gondor.apana.org.au \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox