From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Google-Smtp-Source: AH8x227WErG+UFde6WctZHI5BcKdd2p3EOutZNCtpph8LXwLT846FZqjxY++w3+zpphnJnA049Od ARC-Seal: i=1; a=rsa-sha256; t=1517408519; cv=none; d=google.com; s=arc-20160816; b=yCiQCxj6qKZs01eJGg7owiV3hwRvz0p4t+q/JVarsGBL2LkIBDTr8eJusRbu+MMGNY 6toI0W5jIb7xIIyxkidqeLmIt2ydkL/oZKTx7M+ng6iOaq2QwMDorKQld570bd6cI7sJ rx0Lk2m9KdFeunxWu7ZyERmI+mb3bQsy9krF0BVbQXRPbTZoWbhDdD7/kaKoAMFr/mQQ sG7yl9DG2c9eFlq7NqyyBS1ha6+j/b28w/15nuJGJJ6L1h0IZF8ZuGSg9pghfbf9cGhy YlaPtVf2M97TQWEWitOUMXkr68OgS2X7bHO4KgogEW1VAa6P0QYg5XRikEmUmKNO4wIe xTyw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=user-agent:in-reply-to:content-disposition:mime-version:references :message-id:subject:cc:to:from:date:delivered-to:list-id :list-subscribe:list-unsubscribe:list-help:list-post:precedence :mailing-list:arc-authentication-results; bh=bAoWWjIkyvpfbiZVdjGQn4NOm0t0VOJV47Wzm+vGpY0=; b=gAIZG232kdBblsp/ynOqf3jkHH3oEtN55Mj+bwpA5Ue384dkI27NyZ4w1Es92qPZ6h mapTVp84GL7a25fV1EB7ASm7TrY53MQoMcKkHskFVh7Y3VnKNW06U5VI30fDPg1AL8WA AjrPn0oRm0aNS86HAsXfvX9kktx/2rEF56fflulJX0fRFCOA+za7b63RgHvtpae9N51t mpybLriZga3loXlmsD8GDGvbcNFTMwWtmpAouq22MxBS4LqJqwmOG/bkfWk9AEsBFVXV t3OVqoZ5FCt+pZ1XZfJyxBFNHcuhFpD95zwlfUMK49S2/RSR+35lVcvVQ3Rgh5I8jMwo PZpA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of kernel-hardening-return-11547-gregkh=linuxfoundation.org@lists.openwall.com designates 195.42.179.200 as permitted sender) smtp.mailfrom=kernel-hardening-return-11547-gregkh=linuxfoundation.org@lists.openwall.com Authentication-Results: mx.google.com; spf=pass (google.com: domain of kernel-hardening-return-11547-gregkh=linuxfoundation.org@lists.openwall.com designates 195.42.179.200 as permitted sender) smtp.mailfrom=kernel-hardening-return-11547-gregkh=linuxfoundation.org@lists.openwall.com Mailing-List: contact kernel-hardening-help@lists.openwall.com; run by ezmlm List-Post: List-Help: List-Unsubscribe: List-Subscribe: Date: Wed, 31 Jan 2018 15:21:38 +0100 From: Greg KH To: "Van De Ven, Arjan" Cc: Ingo Molnar , "Williams, Dan J" , Linus Torvalds , Thomas Gleixner , linux-arch , Cyril Novikov , Kernel Hardening , Peter Zijlstra , Catalin Marinas , X86 ML , Will Deacon , Russell King , Ingo Molnar , "H. Peter Anvin" , Alan Cox , Linux Kernel Mailing List , Peter Zijlstra Subject: Re: [PATCH v5 02/12] array_idx: sanitize speculative array de-references Message-ID: <20180131142138.GA9233@kroah.com> References: <151703972396.26578.7326612698912543866.stgit@dwillia2-desk3.amr.corp.intel.com> <20180128085500.djlm5rlbhjlpfj4i@gmail.com> <0575AF4FD06DD142AD198903C74E1CC87A6048F5@ORSMSX103.amr.corp.intel.com> <20180131080310.ebqtxe5p7j54wglj@gmail.com> <0575AF4FD06DD142AD198903C74E1CC87A605256@ORSMSX103.amr.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0575AF4FD06DD142AD198903C74E1CC87A605256@ORSMSX103.amr.corp.intel.com> User-Agent: Mutt/1.9.3 (2018-01-21) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-LABELS: =?utf-8?b?IlxcU2VudCI=?= X-GMAIL-THRID: =?utf-8?q?1590732017653801778?= X-GMAIL-MSGID: =?utf-8?q?1591118156233809335?= X-Mailing-List: linux-kernel@vger.kernel.org List-ID: On Wed, Jan 31, 2018 at 02:13:45PM +0000, Van De Ven, Arjan wrote: > > > short term there was some extremely rudimentary static analysis done. clearly > > > that has extreme limitations both in insane rate of false positives, and missing > > > cases. > > > > What was the output roughly, how many suspect places that need > > array_idx_nospec() > > handling: a few, a few dozen, a few hundred or a few thousand? > > > > I'm guessing 'static tool emitted hundreds of sites with many false positives > > included, but the real sites are probably a few dozen' - but that's really just a > > very, very wild guess. > > your guess is pretty accurate; we ended up with some 15 or so places > (the first patch kit Dan mailed out) But in looking at that first patch set, I don't see many, if any, that could be solved with your proposal of copy_from_user_struct(). The two networking patches couldn't, the scsi one was just bizarre (seriously, you had to trust the input from the hardware, if not, there's worse things happening), and the networking drivers were dealing with other data streams I think. So while I love the idea of copy_from_user_struct(), I don't see it as any type of "this will solve the issues we are trying to address here" solution :( I've been emailing the Coverity people recently about this, and they say they are close to having a ruleset/test that can identify this data pattern better than the original tool that Intel and others came up with. But as I haven't seen the output of it yet, I have no idea if that's true or not. Hopefully they will release it in a few days so we can get an idea of if this is even going to be possible to automatically scan for at all with their tool. Other than Coverity, I don't know of any other tool that is trying to even identify this pattern :( > > Also, IMHO any tooling should very much be open source: this isn't the kind of > > bug > > that can be identified via code review, so there's no fall-back detection method > > like we have for buffer overflows. > > we absolutely need some good open source tooling; my personal > preference will be a compiler plugin; that way you can use all the > fancy logic inside the compilers for analysis, and you can make a "I > don't care just fix it" option in addition to flagging for human > inspection as the kernel would. I thought gcc plugins were going to enable this type of analysis, or maybe clang plugins, but I have yet to hear of anyone working on this. thanks, greg k-h