kernel-hardening - Re: [PATCH v4 01/29] bluetooth: Switch SMP to crypto_cipher_encrypt

Follow @Openwall on Twitter for new release announcements and other news

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <73C272C5-ECDB-4508-B8D3-1F54D5E8E6AB@holtmann.org>
Date: Mon, 4 Jul 2016 19:56:00 +0200
From: Marcel Holtmann <marcel@...tmann.org>
To: Andy Lutomirski <luto@...capital.net>
Cc: Ingo Molnar <mingo@...nel.org>,
 Andy Lutomirski <luto@...nel.org>,
 X86 ML <x86@...nel.org>,
 LKML <linux-kernel@...r.kernel.org>,
 linux-arch <linux-arch@...r.kernel.org>,
 Borislav Petkov <bp@...en8.de>,
 Nadav Amit <nadav.amit@...il.com>,
 Kees Cook <keescook@...omium.org>,
 Brian Gerst <brgerst@...il.com>,
 "kernel-hardening@...ts.openwall.com" <kernel-hardening@...ts.openwall.com>,
 Linus Torvalds <torvalds@...ux-foundation.org>,
 Josh Poimboeuf <jpoimboe@...hat.com>,
 Jann Horn <jann@...jh.net>,
 Heiko Carstens <heiko.carstens@...ibm.com>,
 "Gustavo F. Padovan" <gustavo@...ovan.org>,
 Johan Hedberg <johan.hedberg@...il.com>,
 "David S. Miller" <davem@...emloft.net>,
 linux-bluetooth@...r.kernel.org,
 Network Development <netdev@...r.kernel.org>
Subject: Re: [PATCH v4 01/29] bluetooth: Switch SMP to crypto_cipher_encrypt_one()

Hi Andy,

>>>>> 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.
>>>>> 
>>>>> Cc: Marcel Holtmann <marcel@...tmann.org>
>>>>> Cc: Gustavo Padovan <gustavo@...ovan.org>
>>>>> Cc: Johan Hedberg <johan.hedberg@...il.com>
>>>>> Cc: "David S. Miller" <davem@...emloft.net>
>>>>> Cc: linux-bluetooth@...r.kernel.org
>>>>> Cc: netdev@...r.kernel.org
>>>>> Acked-by: Herbert Xu <herbert@...dor.apana.org.au>
>>>>> Acked-and-tested-by: Johan Hedberg <johan.hedberg@...el.com>
>>>>> Signed-off-by: Andy Lutomirski <luto@...nel.org>
>>>>> ---
>>>>> net/bluetooth/smp.c | 67 ++++++++++++++++++++++-------------------------------
>>>>> 1 file changed, 28 insertions(+), 39 deletions(-)
>>>> 
>>>> patch has been applied to bluetooth-next tree.
>>> 
>>> Sadly carrying this separately will delay the virtual kernel stacks feature by a
>>> kernel cycle, because it's a must-have prerequisite.
>> 
>> I can take it back out, but then I have the fear the the ECDH change to use KPP for SMP might be the one that has to wait a kernel cycle. Either way is fine with me, but I want to avoid nasty merge conflicts in the Bluetooth SMP code.
> 
> Nothing goes wrong if an identical patch is queued in both places,
> right?  Or, if you prefer not to duplicate it, could one of you commit
> it and the other one pull it?  Ingo, given that this is patch 1 in the
> series and unlikely to change, if you want to make this whole thing
> have a separate branch in -tip, this could live there for starters.
> (But, if you do so, please make sure you base off a very new copy of
> Linus' tree -- the series is heavily dependent on the thread_info
> change he applied a few days ago.)

so what are doing now? I take this back out or we keep it in and let git deal with it when merging the trees?

Regards

Marcel

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.