From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752225AbcGNUlu (ORCPT ); Thu, 14 Jul 2016 16:41:50 -0400 Received: from shards.monkeyblade.net ([184.105.139.130]:33928 "EHLO shards.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751224AbcGNUlq (ORCPT ); Thu, 14 Jul 2016 16:41:46 -0400 Date: Thu, 14 Jul 2016 13:41:44 -0700 (PDT) Message-Id: <20160714.134144.1427497707130106328.davem@davemloft.net> To: luto@amacapital.net Cc: luto@kernel.org, x86@kernel.org, linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org, bp@alien8.de, nadav.amit@gmail.com, keescook@chromium.org, brgerst@gmail.com, kernel-hardening@lists.openwall.com, torvalds@linux-foundation.org, jpoimboe@redhat.com, jann@thejh.net, heiko.carstens@de.ibm.com, marcel@holtmann.org, gustavo@padovan.org, johan.hedberg@gmail.com, linux-bluetooth@vger.kernel.org, netdev@vger.kernel.org Subject: Re: [PATCH v5 01/32] bluetooth: Switch SMP to crypto_cipher_encrypt_one() From: David Miller In-Reply-To: References: <264af59a3060c2bc2a725cfc66a8fa68219d1c4a.1468270393.git.luto@kernel.org> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.12 (shards.monkeyblade.net [149.20.54.216]); Thu, 14 Jul 2016 13:41:45 -0700 (PDT) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Andy Lutomirski Date: Thu, 14 Jul 2016 12:10:45 -0700 > On Mon, Jul 11, 2016 at 1:53 PM, Andy Lutomirski wrote: >> SMP does ECB crypto on stack buffers. This is complicated and >> fragile, and it will not work if the stack is virtually allocated. >> >> Switch to the crypto_cipher interface, which is simpler and safer. > > Hi Dave- > > It looks like we're delaying virtually mapped stacks to 4.9. That > means that there's time for this to go in through net-next. Could you > queue it up? This needs to go via the bluetooth maintainer, who will surely pass it properly my way.