From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by galois.linutronix.de (Postfix) with ESMTPS id 74A2840340 for ; Tue, 14 Jul 2020 10:44:11 +0200 (CEST) Date: Tue, 14 Jul 2020 10:44:07 +0200 From: Greg KH Subject: [MODERATED] Re: [PATCH] Raffle 0 Message-ID: <20200714084407.GB1168379@kroah.com> References: <5f0cf7c5.1c69fb81.99805.3f5fSMTPIN_ADDED_BROKEN@mx.google.com> <20200714055735.GB655193@kroah.com> <676ec4fc-b0df-91a6-92af-46c6c51663ed@citrix.com> <20200714081409.GA862637@kroah.com> <20200714082008.GA1018017@kroah.com> MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: speck@linutronix.de List-ID: On Tue, Jul 14, 2020 at 09:36:47AM +0100, speck for Andrew Cooper wrote: > On 14/07/2020 09:20, speck for Greg KH wrote: > > On Tue, Jul 14, 2020 at 10:14:09AM +0200, speck for Greg KH wrote: > >> On Tue, Jul 14, 2020 at 09:03:41AM +0100, speck for Andrew Cooper wrote: > >>> On 14/07/2020 06:57, speck for Greg KH wrote: > >>>> Also, why is this being sent to speck? What is wrong with the normal > >>>> development process? > >>> This has a CVE attached to it, and an embargo in November (both of which > >>> ought to be more clear in the email and/or commit message IMO). > >> That was totally not obvious, how were we supposed to guess that? > > Clearly need to improve our divination skills... > > (It is part of the bundle of issues for the next IPU.) I don't know what "IPU" means :( > >>> Researchers have demonstrated a power analysis side-channel to recover > >>> keys from the AES-NI instructions, usable by unprivileged userspace > >>> given these world-usable perms. > >> Ok, then why send this to us now, why not just submit this to upstream > >> at the proper time when the embargo expires? Why do we now need to sit > >> on this for the next 4 fricken months? > > And why sit on this at all anyway? > > The companion CVE, for a malicious kernel attacking SGX with this > mechanism, needs a microcode change, which is why they are bundled together. But again, that's independant of this sysfs file permissions, right? Why can't you just fix this now, so when the other mess is finally public you don't have to worry about it. Much like I did for the random number stuff, we fixed the kernel up to not depend on it way before Intel came up with BIOS fixes and the other stuff. Get ahead of the issue if at all possible. thanks, greg k-h