From patchwork Mon Oct 17 09:14:28 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Ard Biesheuvel X-Patchwork-Id: 77718 Delivered-To: patch@linaro.org Received: by 10.140.97.247 with SMTP id m110csp299684qge; Mon, 17 Oct 2016 02:14:36 -0700 (PDT) X-Received: by 10.67.7.100 with SMTP id db4mr30775055pad.106.1476695676128; Mon, 17 Oct 2016 02:14:36 -0700 (PDT) Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id a4si29938054pfk.273.2016.10.17.02.14.35; Mon, 17 Oct 2016 02:14:36 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-wireless-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org; spf=pass (google.com: best guess record for domain of linux-wireless-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-wireless-owner@vger.kernel.org; dmarc=pass (p=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933633AbcJQJOb (ORCPT + 1 other); Mon, 17 Oct 2016 05:14:31 -0400 Received: from mail-io0-f171.google.com ([209.85.223.171]:34064 "EHLO mail-io0-f171.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933168AbcJQJO3 (ORCPT ); Mon, 17 Oct 2016 05:14:29 -0400 Received: by mail-io0-f171.google.com with SMTP id r30so181407471ioi.1 for ; Mon, 17 Oct 2016 02:14:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=JprKegZdCUkLh095+q7X5k6WIHGnFQxHFwfZ4uayxXw=; b=e/7B6ZyAcWrpKjwPcRurN96j8QiT/LL1JtFhYS9nIDgqkgYUQqLGQmcCo8TTtQbwD4 Ck6bPOwFgdoZB+U3tyYzZOjE9dWrqbP2/Uxv4xLgp6HEP/v/cLWVkhnrNXpStahmeGqD pi4r3JQ+VXml4FcmWgRSicZSH34DYl5LAosOk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=JprKegZdCUkLh095+q7X5k6WIHGnFQxHFwfZ4uayxXw=; b=EXwjl0kN0nSCm3XeaTCM+BzbN765eFsw5Fpq+MRfXowz3TCU5Nm/wIuOlRbRJbQlx9 m1btv1InVYeRyo2O9BvPAiVqOi0Bg6KofWdlL+p/znoYTpisWiZB1WlwC/sdcr0HxdnI PxLHxy9WRYgM2TpW0H2cNVvTXM89seAqfhCa5Kca2bC4WHw2ncmmplnLLMyhfoPP/HfB piDkTjTDARIFv+T38BmLeR9vgvz21h+jZ8UayNA74gDTty/E9JxgvdxSY4vG30O25Txl TG4dZotA7BkzHlc17Us9RF8KBpjJVXrlGL4yimmnrsWssVLASse1NvkgjgbKKNcbYv1O HDCg== X-Gm-Message-State: AA6/9RkfGyy7u+Xs8w48fuHzpbpXeZzFOJKZ5c7tWTFb/+jvedW/N57/45ryyq8JScsTo5cWFCfcqLafAgG2YKKY X-Received: by 10.107.156.137 with SMTP id f131mr20663308ioe.83.1476695668966; Mon, 17 Oct 2016 02:14:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.5.139 with HTTP; Mon, 17 Oct 2016 02:14:28 -0700 (PDT) In-Reply-To: <1476693195-14071-1-git-send-email-johannes@sipsolutions.net> References: <1476693195-14071-1-git-send-email-johannes@sipsolutions.net> From: Ard Biesheuvel Date: Mon, 17 Oct 2016 10:14:28 +0100 Message-ID: Subject: Re: [PATCH v4] mac80211: move extra crypto data off the stack To: Johannes Berg Cc: "" , Sergey Senozhatsky , "" , Herbert Xu , Johannes Berg Sender: linux-wireless-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-wireless@vger.kernel.org On 17 October 2016 at 09:33, Johannes Berg wrote: > From: Johannes Berg > > As the stack can (on x86-64) now be virtually mapped rather than > using "normal" kernel memory, Sergey noticed mac80211 isn't using > the SG APIs correctly by putting on-stack buffers into SG tables. > This leads to kernel crashes. > > Fix this by allocating the extra fields dynamically on the fly as > needed, using a kmem cache. > > I used per-CPU memory in a previous iteration of this patch, but > Ard Biesheuvel pointed out that was also vmalloc'ed on some > architectures. > > Reported-by: Sergey Senozhatsky > Signed-off-by: Johannes Berg Apologies for going back and forth on this, but it appears there may be another way to deal with this. First of all, we only need this handling for the authenticated data, and only for CCM and GCM, not CMAC (which does not use scatterlists at all, it simply calls the AES cipher directly) So that leaves a fixed 20 bytes for GCM and fixed 32 bytes for CCM, which we could allocate along with the AEAD request, e..g., """ @@ -49,6 +53,7 @@ int ieee80211_aes_ccm_decrypt(struct crypto_aead *tfm, u8 *b_0, u8 *aad, { struct scatterlist sg[3]; struct aead_request *aead_req; + u8 *__aad; int err; if (data_len == 0) @@ -58,8 +63,11 @@ int ieee80211_aes_ccm_decrypt(struct crypto_aead *tfm, u8 *b_0, u8 *aad, if (!aead_req) return -ENOMEM; + __aad = (u8 *)aead_req + crypto_aead_reqsize(tfm); + memcpy(__aad, aad, 2 * AES_BLOCK_SIZE); + sg_init_table(sg, 3); - sg_set_buf(&sg[0], &aad[2], be16_to_cpup((__be16 *)aad)); + sg_set_buf(&sg[0], &__aad[2], be16_to_cpup((__be16 *)__aad)); sg_set_buf(&sg[1], data, data_len); sg_set_buf(&sg[2], mic, mic_len); @@ -90,6 +98,8 @@ struct crypto_aead *ieee80211_aes_key_setup_encrypt(const u8 key[], if (err) goto free_aead; + crypto_aead_set_reqsize(tfm, + crypto_aead_reqsize(tfm) + 2 * AES_BLOCK_SIZE)); return tfm; free_aead: """ diff --git a/net/mac80211/aes_ccm.c b/net/mac80211/aes_ccm.c index 8e898a6e8de8..c0c33e6ad94e 100644 --- a/net/mac80211/aes_ccm.c +++ b/net/mac80211/aes_ccm.c @@ -24,13 +24,17 @@ int ieee80211_aes_ccm_encrypt(struct crypto_aead *tfm, u8 *b_0, u8 *aad, { struct scatterlist sg[3]; struct aead_request *aead_req; + u8 *__aad; aead_req = aead_request_alloc(tfm, GFP_ATOMIC); if (!aead_req) return -ENOMEM; + __aad = (u8 *)aead_req + crypto_aead_reqsize(tfm); + memcpy(__aad, aad, 2 * AES_BLOCK_SIZE); + sg_init_table(sg, 3); - sg_set_buf(&sg[0], &aad[2], be16_to_cpup((__be16 *)aad)); + sg_set_buf(&sg[0], &__aad[2], be16_to_cpup((__be16 *)__aad)); sg_set_buf(&sg[1], data, data_len); sg_set_buf(&sg[2], mic, mic_len);