Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752484AbeADR6l (ORCPT + 1 other); Thu, 4 Jan 2018 12:58:41 -0500 Received: from mail-oi0-f65.google.com ([209.85.218.65]:39900 "EHLO mail-oi0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751957AbeADR6j (ORCPT ); Thu, 4 Jan 2018 12:58:39 -0500 X-Google-Smtp-Source: ACJfBouYWegleS3kkxyWSjYEknFM7FZV35Iq1g1iDIguL/SKNFTsA3uILUB2IY67HaMEKJHL9fhC/Y9ue3kePInpj+Q= MIME-Version: 1.0 In-Reply-To: References: <20180103223827.39601-1-mark.rutland@arm.com> <151502463248.33513.5960736946233335087.stgit@dwillia2-desk3.amr.corp.intel.com> <20180104010754.22ca6a74@alans-desktop> From: Dan Williams Date: Thu, 4 Jan 2018 09:58:37 -0800 Message-ID: Subject: Re: [RFC PATCH] asm/generic: introduce if_nospec and nospec_barrier To: Julia Lawall Cc: Alan Cox , Linus Torvalds , Linux Kernel Mailing List , Mark Rutland , linux-arch@vger.kernel.org, Peter Zijlstra , Greg KH , Thomas Gleixner , Elena Reshetova , Alan Cox , Dan Carpenter Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Return-Path: On Wed, Jan 3, 2018 at 10:28 PM, Julia Lawall wrote: > > > On Wed, 3 Jan 2018, Dan Williams wrote: > >> [ adding Julia and Dan ] >> >> On Wed, Jan 3, 2018 at 5:07 PM, Alan Cox wrote: >> > On Wed, 3 Jan 2018 16:39:31 -0800 >> > Linus Torvalds wrote: >> > >> >> On Wed, Jan 3, 2018 at 4:15 PM, Dan Williams wrote: >> >> > The 'if_nospec' primitive marks locations where the kernel is disabling >> >> > speculative execution that could potentially access privileged data. It >> >> > is expected to be paired with a 'nospec_{ptr,load}' where the user >> >> > controlled value is actually consumed. >> >> >> >> I'm much less worried about these "nospec_load/if" macros, than I am >> >> about having a sane way to determine when they should be needed. >> >> >> >> Is there such a sane model right now, or are we talking "people will >> >> randomly add these based on strong feelings"? >> > >> > There are people trying to tune coverity and other tool rules to identify >> > cases, and some of the work so far was done that way. For x86 we didn't >> > find too many so far so either the needed pattern is uncommon or .... 8) >> > >> > Given you can execute over a hundred basic instructions in a speculation >> > window it does need to be a tool that can explore not just in function >> > but across functions. That's really tough for the compiler itself to do >> > without help. >> > >> > What remains to be seen is if there are other patterns that affect >> > different processors. >> > >> > In the longer term the compiler itself needs to know what is and isn't >> > safe (ie you need to be able to write things like >> > >> > void foo(tainted __user int *x) >> > >> > and have the compiler figure out what level of speculation it can do and >> > (on processors with those features like IA64) when it can and can't do >> > various kinds of non-trapping loads. >> > >> >> It would be great if coccinelle and/or smatch could be taught to catch >> some of these case at least as a first pass "please audit this code >> block" type of notification. >> > > What should one be looking for. Do you have a typical example? > See "Exploiting Conditional Branch Misprediction" from the paper [1]. The typical example is an attacker controlled index used to trigger a dependent read near a branch. Where an example of "near" from the paper is "up to 188 simple instructions inserted in the source code between the ‘if’ statement and the line accessing array...". if (attacker_controlled_index < bound) val = array[attacker_controlled_index]; else return error; ...when the cpu speculates that the 'index < bound' branch is taken it reads index and uses that value to read array[index]. The result of an 'array' relative read is potentially observable in the cache. [1]: https://spectreattack.com/spectre.pdf