Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753279AbeADVnQ (ORCPT + 1 other); Thu, 4 Jan 2018 16:43:16 -0500 Received: from mail-oi0-f41.google.com ([209.85.218.41]:44114 "EHLO mail-oi0-f41.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752617AbeADVnO (ORCPT ); Thu, 4 Jan 2018 16:43:14 -0500 X-Google-Smtp-Source: ACJfBoteec9meR/YcFOkyIehqgkdBnJQ/L6f4NbQ7AFp9PUzLll6hPUn8gDFiQx3zYA4qkyr/1abIR+EkHvoqKkSxLY= MIME-Version: 1.0 In-Reply-To: <20180104192648.GA10427@amd> References: <20180103223827.39601-1-mark.rutland@arm.com> <151502463248.33513.5960736946233335087.stgit@dwillia2-desk3.amr.corp.intel.com> <20180104010754.22ca6a74@alans-desktop> <20180104192648.GA10427@amd> From: Dan Williams Date: Thu, 4 Jan 2018 13:43:13 -0800 Message-ID: Subject: Re: [RFC PATCH] asm/generic: introduce if_nospec and nospec_barrier To: Pavel Machek Cc: Julia Lawall , 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 Thu, Jan 4, 2018 at 11:26 AM, Pavel Machek wrote: > Hi! > >> >> > 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. > > You still need > > (void) array2[val]; > > after that to get something observable, right? As far as I understand the presence of array2[val] discloses more information, but in terms of the cpu taking an action that it is observable in the cache that's already occurred when "val = array[attacker_controlled_index];" is speculated. Lets err on the side of caution and shut down all the observable actions that are already explicitly gated by an input validation check. In other words, a low bandwidth information leak is still a leak.