linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Johannes Berg <johannes@sipsolutions.net>
To: Andy Lutomirski <luto@amacapital.net>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>,
	"linux-next@vger.kernel.org" <linux-next@vger.kernel.org>,
	Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>,
	Network Development <netdev@vger.kernel.org>,
	Sergey Senozhatsky <sergey.senozhatsky@gmail.com>,
	Herbert Xu <herbert@gondor.apana.org.au>,
	"David S. Miller" <davem@davemloft.net>,
	Linux Wireless List <linux-wireless@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Ard Biesheuvel <ard.biesheuvel@linaro.org>
Subject: Re: [mac80211] BUG_ON with current -git (4.8.0-11417-g24532f7)
Date: Fri, 14 Oct 2016 09:25:16 +0200	[thread overview]
Message-ID: <1476429916.4382.12.camel@sipsolutions.net> (raw)
In-Reply-To: <CALCETrW8imkGTtR9-mFB=e=Gdr1QXVuhXN3GRs2B6wbmPaaGhA@mail.gmail.com> (sfid-20161013_235018_225755_5BCF27D2)

On Thu, 2016-10-13 at 14:49 -0700, Andy Lutomirski wrote:
> 
> It's failing before that.  With CONFIG_VMAP_STACK=y, the stack may
> not be physically contiguous and can't be used for DMA, so putting it
> in a scatterlist is bogus in general, and the crypto code mostly
> wants a scatterlist.

I see, so all this stuff is getting inlined, and we crash in
sg_set_buf() because it does sg_set_page() and that obviously needs to
do virt_to_page(), which is invalid on this address now.
With CONFIG_DEBUG_SG we'd have hit the BUG_ON there instead.

It does indeed look like AEAD doesn't have any non-SG API.

So ultimately, the bug already goes back to Ard's commit 7ec7c4a9a686
("mac80211: port CCMP to cryptoapi's CCM driver") since that already
potentially used stack space for DMA.

Since we don't have any space in the SKB or anywhere else at this point
(other than the stack that we can't use), I see two ways out of this:

   1. revert that patch (doing so would need some major adjustments now,
      since it's pretty old and a number of new things were added in the
      meantime)
   2. allocate a per-CPU buffer for all the things that we put on the
      stack and use in SG lists, those are:
       * CCM/GCM: AAD (32B), B_0/J_0 (16B)
       * GMAC: AAD (20B), zero (16B)
       * (not sure why CMAC isn't using this API, but it would be like
      GMAC)

Thoughts?

johannes

  reply	other threads:[~2016-10-14  7:25 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-10-10 15:03 [mac80211] BUG_ON with current -git (4.8.0-11417-g24532f7) Sergey Senozhatsky
2016-10-10 15:30 ` Sergey Senozhatsky
2016-10-12  9:05   ` Johannes Berg
2016-10-12 14:12     ` Sergey Senozhatsky
2016-10-12 14:22       ` Johannes Berg
2016-10-13  5:39         ` Andy Lutomirski
2016-10-13  6:02           ` Johannes Berg
2016-10-13 13:42             ` Sergey Senozhatsky
2016-10-13 13:45               ` Sergey Senozhatsky
2016-10-13 13:45               ` Johannes Berg
2016-10-13 15:00                 ` Sergey Senozhatsky
2016-10-13 15:04                   ` Sergey Senozhatsky
2016-10-13 21:49                 ` Andy Lutomirski
2016-10-14  7:25                   ` Johannes Berg [this message]
2016-10-14  8:28                     ` Johannes Berg
2016-10-14  8:39                       ` Ard Biesheuvel
2016-10-14  8:41                         ` Ard Biesheuvel
2016-10-14  8:42                           ` Johannes Berg
2016-10-14  8:47                             ` Ard Biesheuvel
2016-10-14  8:55                               ` Johannes Berg
2016-10-14  9:05                                 ` Ard Biesheuvel
2016-10-14  9:10                                   ` Johannes Berg
2016-10-14  9:21                                     ` Ard Biesheuvel
2016-10-14  9:25                                       ` Johannes Berg
2016-10-14  9:35                                         ` Ard Biesheuvel
2016-10-14 10:00                                           ` Johannes Berg
2016-10-14 11:11                                             ` Ard Biesheuvel
2016-10-14  8:53                     ` Johannes Berg
2016-10-14  8:39                   ` Sergey Senozhatsky
2016-10-14  8:45                     ` Johannes Berg

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=1476429916.4382.12.camel@sipsolutions.net \
    --to=johannes@sipsolutions.net \
    --cc=ard.biesheuvel@linaro.org \
    --cc=davem@davemloft.net \
    --cc=herbert@gondor.apana.org.au \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-next@vger.kernel.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=luto@amacapital.net \
    --cc=netdev@vger.kernel.org \
    --cc=sergey.senozhatsky.work@gmail.com \
    --cc=sergey.senozhatsky@gmail.com \
    --cc=sfr@canb.auug.org.au \
    /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;
as well as URLs for NNTP newsgroup(s).