Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754428AbeALGGK (ORCPT + 1 other); Fri, 12 Jan 2018 01:06:10 -0500 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:50752 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754259AbeALGGG (ORCPT ); Fri, 12 Jan 2018 01:06:06 -0500 Subject: Re: [PATCH v2 17/19] qla2xxx: prevent bounds-check bypass via speculative execution From: James Bottomley To: Dan Williams Cc: Linux Kernel Mailing List , linux-arch@vger.kernel.org, "Martin K. Petersen" , linux-scsi , kernel-hardening@lists.openwall.com, qla2xxx-upstream@qlogic.com, Thomas Gleixner , Linus Torvalds , Andrew Morton , Elena Reshetova , Alan Cox Date: Thu, 11 Jan 2018 22:05:55 -0800 In-Reply-To: References: <151571798296.27429.7166552848688034184.stgit@dwillia2-desk3.amr.corp.intel.com> <151571807774.27429.7382333750792304971.stgit@dwillia2-desk3.amr.corp.intel.com> <1515719956.3056.37.camel@linux.vnet.ibm.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.20.5 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-TM-AS-GCONF: 00 x-cbid: 18011206-8235-0000-0000-00000CDBEF38 X-IBM-SpamModules-Scores: X-IBM-SpamModules-Versions: BY=3.00008363; HX=3.00000241; KW=3.00000007; PH=3.00000004; SC=3.00000245; SDB=6.00973792; UDB=6.00493445; IPR=6.00753737; BA=6.00005774; NDR=6.00000001; ZLA=6.00000005; ZF=6.00000009; ZB=6.00000000; ZP=6.00000000; ZH=6.00000000; ZU=6.00000002; MB=3.00018993; XFM=3.00000015; UTC=2018-01-12 06:06:03 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 18011206-8236-0000-0000-00003F36336D Message-Id: <1515737155.3056.48.camel@linux.vnet.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2018-01-12_04:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1709140000 definitions=main-1801120081 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Return-Path: On Thu, 2018-01-11 at 21:38 -0800, Dan Williams wrote: > On Thu, Jan 11, 2018 at 5:19 PM, James Bottomley > wrote: > > > > On Thu, 2018-01-11 at 16:47 -0800, Dan Williams wrote: > > > > > > Static analysis reports that 'handle' may be a user controlled > > > value that is used as a data dependency to read 'sp' from the > > > 'req->outstanding_cmds' array. > > > > Greg already told you it comes from hardware, specifically the > > hardware response queue.  If you don't believe him, I can confirm > > it's quite definitely all copied from the iomem where the mailbox > > response is, so it can't be a user controlled value (well, unless > > the user has some influence over the firmware of the > > qla2xxx  controller, which probably means you have other things to > > worry about than speculative information leaks). > > I do believe him, and I still submitted this. I'm trying to probe at > the meta question of where do we draw the line with these especially > when it costs us relatively little to apply a few line patch? We fix > theoretical lockdep races, why not theoretical data leak paths? I think I've lost the thread of what you're after.  I thought you were asking for the domain experts to look and see if there is the potential for attack; if there's no theoretical way for a user to influence the value what's the point of killing speculation?  Furthermore, if the user could affect that 32 bit value, what they'd actually do is extract information via the que variable which you didn't fix and which could be used to compromise the kernel without resorting to side channel attacks. What's most puzzling to me is the inconsistency of the positions: if it doesn't cost that much to turn off speculation, just do it on kernel entry as Jiří suggested; we can make it a dynamic option and the cloud providers can do it and the rest of us don't need to bother.  If it does cost a lot to turn it off as Alan said, then you need us to identify the cases above where there's no need to disrupt the speculation pipeline and not turn it off there.  Which is it? James