[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <c2fd13f6-a2c9-d11f-d439-abb847ebed3c@wdc.com>
Date: Mon, 8 Jan 2018 08:20:19 -0800
From: Bart Van Assche <bart.vanassche@....com>
To: Dan Williams <dan.j.williams@...el.com>,
"Eric W. Biederman" <ebiederm@...ssion.com>
Cc: Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Mark Rutland <mark.rutland@....com>,
Peter Zijlstra <peterz@...radead.org>,
Alan Cox <alan.cox@...el.com>,
Srinivas Pandruvada <srinivas.pandruvada@...ux.intel.com>,
Will Deacon <will.deacon@....com>,
Solomon Peachy <pizza@...ftnet.org>,
"H. Peter Anvin" <hpa@...or.com>,
Christian Lamparter <chunkeey@...glemail.com>,
Elena Reshetova <elena.reshetova@...el.com>,
linux-arch@...r.kernel.org, Andi Kleen <ak@...ux.intel.com>,
"James E.J. Bottomley" <jejb@...ux.vnet.ibm.com>,
linux-scsi <linux-scsi@...r.kernel.org>,
Jonathan Corbet <corbet@....net>, X86 ML <x86@...nel.org>,
Ingo Molnar <mingo@...hat.com>,
Alexey Kuznetsov <kuznet@....inr.ac.ru>,
Zhang Rui <rui.zhang@...el.com>,
"Linux-media@...r.kernel.org" <linux-media@...r.kernel.org>,
Arnd Bergmann <arnd@...db.de>, Jan Kara <jack@...e.com>,
Eduardo Valentin <edubezval@...il.com>,
Al Viro <viro@...iv.linux.org.uk>, qla2xxx-upstream@...gic.com,
Thomas Gleixner <tglx@...utronix.de>,
Mauro Carvalho Chehab <mchehab@...nel.org>,
Arjan van de Ven <arjan@...ux.intel.com>,
Kalle Valo <kvalo@...eaurora.org>,
Alan Cox <alan@...ux.intel.com>,
"Martin K. Petersen" <martin.petersen@...cle.com>,
Hideaki YOSHIFUJI <yoshfuji@...ux-ipv6.org>,
Greg KH <gregkh@...uxfoundation.org>,
linux-wireless@...r.kernel.org, Netdev <netdev@...r.kernel.org>,
Linus Torvalds <torvalds@...ux-foundation.org>,
"David S. Miller" <davem@...emloft.net>,
Laurent Pinchart <laurent.pinchart@...asonboard.com>
Subject: Re: [PATCH 00/18] prevent bounds-check bypass via speculative
execution
On 01/05/18 22:30, Dan Williams wrote:
> On Fri, Jan 5, 2018 at 6:22 PM, Eric W. Biederman <ebiederm@...ssion.com> wrote:
>> Please expand this.
>>
>> It is not clear what the static analysis is looking for. Have a clear
>> description of what is being fixed is crucial for allowing any of these
>> changes.
>>
>> For the details given in the change description what I read is magic
>> changes because a magic process says this code is vulnerable.
>
> Yes, that was my first reaction to the patches as well, I try below to
> add some more background and guidance, but in the end these are static
> analysis reports across a wide swath of sub-systems. It's going to
> take some iteration with domain experts to improve the patch
> descriptions, and that's the point of this series, to get the better
> trained eyes from the actual sub-system owners to take a look at these
> reports.
More information about what the static analysis is looking for would
definitely be welcome.
Additionally, since the analysis tool is not publicly available, how are
authors of new kernel code assumed to verify whether or not their code
needs to use nospec_array_ptr()? How are reviewers of kernel code
assumed to verify whether or not nospec_array_ptr() is missing where it
should be used?
Since this patch series only modifies the upstream kernel, how will
out-of-tree drivers be fixed, e.g. the nVidia driver and the Android
drivers?
Thanks,
Bart.
Powered by blists - more mailing lists