Date: Thu, 11 Jan 2018 22:05:55 -0800 From: James Bottomley <jejb@...ux.vnet.ibm.com> To: Dan Williams <dan.j.williams@...el.com> Cc: Linux Kernel Mailing List <linux-kernel@...r.kernel.org>, linux-arch@...r.kernel.org, "Martin K. Petersen" <martin.petersen@...cle.com>, linux-scsi <linux-scsi@...r.kernel.org>, kernel-hardening@...ts.openwall.com, qla2xxx-upstream@...gic.com, Thomas Gleixner <tglx@...utronix.de>, Linus Torvalds <torvalds@...ux-foundation.org>, Andrew Morton <akpm@...ux-foundation.org>, Elena Reshetova <elena.reshetova@...el.com>, Alan Cox <alan@...ux.intel.com> Subject: Re: [PATCH v2 17/19] qla2xxx: prevent bounds-check bypass via speculative execution On Thu, 2018-01-11 at 21:38 -0800, Dan Williams wrote: > On Thu, Jan 11, 2018 at 5:19 PM, James Bottomley > <jejb@...ux.vnet.ibm.com> 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
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.