From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: ARC-Seal: i=1; a=rsa-sha256; t=1517385794; cv=none; d=google.com; s=arc-20160816; b=cp4HcyYz3t+tsBdNwb0yehtEh4U0FEm+o4Bn0J9+7QJbQ/QaUdGCeEEjpqcLiFiUPA eL0bKWLQyFieqAZwMkQRCkPSH9nTZznEOSUQOSCMhY5ct7/iA260HLTmKdAvlWE0QYhJ yoP4SL3TsqYDIPZDcaL3b8hI8xSCODpTjkfiirqZRm1jMPA6Gl3SZm5VkeKRadJIpUee COOJeBtd5McXXZhnZDU71EFZIC3pTDFMghgy0z64YmlWdx2Du8dFzXNr73hDhs+4ERG0 32GsNcAS/0fUvn0VJ7FnOdgx3FT4HzYdEukuAlNcr3p2Eq7CAdtpKAVnbw85H3vkOUw0 1H8g== 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:sender:dkim-signature :arc-authentication-results; bh=FxG3ZOJqDeUjxQF08/Ie8mLTal2buNxAa6y3IajvuFQ=; b=NZ9dXoI0mT3S/Enu0r4t2m1qPseZiv4EfUujUvE+/yRHtnbxAIIyDLKgIGIkfHpeVg lKXKLmkcK1kzoBXMF4UI8njXfrHdtTtJP8wYl/EQFQT9MfybaCsKzegEOkQdtOzrtSxC HyU6D/Ebi25AUmtKDDWppQUXeYUjVZDvy5yZvd/2hfw/1a5jnr8uRFwc4iZVNj2I3Gjj QiWKqIajUwt9P69YjdWN8WoS91Tk9ByQDTPGirxrUlkBMqoE/oEA81jz7A1cwjfuiSOW BEvlem/IEp2RdoFiU8s+9qHyFOr+9JLqPFiAwLAPZxjMXAGemg+Ip/g3vTOtYY8olgG4 /1TQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=aovO4b5R; spf=pass (google.com: domain of mingo.kernel.org@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=mingo.kernel.org@gmail.com Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=aovO4b5R; spf=pass (google.com: domain of mingo.kernel.org@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=mingo.kernel.org@gmail.com X-Google-Smtp-Source: AH8x226haKHGe1Y64GtG8GxfWsA4WnKf7ywHUDvg75cceZy16NEM0mY6yKW9rO9ZOJiHZbB+PO23FQ== Sender: Ingo Molnar Date: Wed, 31 Jan 2018 09:03:10 +0100 From: Ingo Molnar To: "Van De Ven, Arjan" Cc: "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 , Greg KH , "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: <20180131080310.ebqtxe5p7j54wglj@gmail.com> References: <151703971300.26578.1185595719337719486.stgit@dwillia2-desk3.amr.corp.intel.com> <151703972396.26578.7326612698912543866.stgit@dwillia2-desk3.amr.corp.intel.com> <20180128085500.djlm5rlbhjlpfj4i@gmail.com> <0575AF4FD06DD142AD198903C74E1CC87A6048F5@ORSMSX103.amr.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0575AF4FD06DD142AD198903C74E1CC87A6048F5@ORSMSX103.amr.corp.intel.com> User-Agent: NeoMutt/20170609 (1.8.3) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: =?utf-8?q?1590732017653801778?= X-GMAIL-MSGID: =?utf-8?q?1591094325860414034?= X-Mailing-List: linux-kernel@vger.kernel.org List-ID: * Van De Ven, Arjan wrote: > > > IOW, is there some work on tooling/analysis/similar? Not asking for > > > near-term, but more of a "big picture" question.. > > 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. Our whole mindset and approach with these generic APIs obviously very much depends on the order of magnitude: - For array users up to a few dozen per 20 MLOC code base accumulated over 20 years, and with no more than ~1 new site per kernel release we can probably do what we do for buffer overflows: static analyze and fix via array_idx_nospec(). - If it's more than a few dozen then intuitively I'd also be very much in favor of compiler help: for example trickle down __user annotations that Sparse uses some more and let the compiler sanitize indices or warn about them - without hurting performance of in-kernel array handling. - If it's "hundreds" then probably both the correctness and the maintenance aspects won't scale well to a 20+ MLOC kernel code base - in that case we _have_ to catch the out of range values at a much earlier stage, at the system call and other system ABI level, and probably need to do it via a self-maintaining approach such as annotations/types that also warns about 'unsanitized' uses. But filtering earlier has its own problems as well: mostly the layering violations (high level interfaces often don't know the safe array index range) can create worse bugs and more fragility than what is being fixed ... - If it's "thousands" then it _clearly_ won't scale and we probably need compiler help: i.e. a compiler that tracks ranges and automatically sanitizes indices. This will have some performance effect, but should result in almost immediate correctness. 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. Anyway, the approach taken very much depends on the order of magnitude of such affected array users we are targeting ... Thanks, Ingo