From patchwork Fri Feb 23 10:41:59 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jack Wang X-Patchwork-Id: 129353 Delivered-To: patch@linaro.org Received: by 10.46.66.2 with SMTP id p2csp449446lja; Fri, 23 Feb 2018 02:42:36 -0800 (PST) X-Google-Smtp-Source: AH8x225yX8PXGh5bwKgzGNHBBkl025Be1J391cXOL0UIbUUAyQNAymxnhMwUKnyzWKJ3b3Wv0zpj X-Received: by 10.99.51.77 with SMTP id z74mr1136515pgz.120.1519382556473; Fri, 23 Feb 2018 02:42:36 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1519382556; cv=none; d=google.com; s=arc-20160816; b=jTcz8bXZaFmTwFYE0NYsN6WQ7rWxTz6wUXLx8e7Hxj0WhBs54EP/SsTbHZic8NbxhY ydfGzOcu0HSwW/VYyhSGvViE1OjfzMK6wjse2COra6mMLErXalGO7DVWryNn7Oa7hUvA s7gF3GYXa0BEir5kBErhVgI6ZDdOoyLhnk7JpA3+RKvU8Sxtix1svLNXH465/7Y0HfgI uHcKOPTOximNMLMmjC5kL6C++gNn5R3B0XBd0k8IsvKMy4ntzE7qF+tP/ddyNoeIJK1n ggy6dfGEl77Pd9xWHUYo2GvhUc1uoRvWsDCN6F16Dv5RephigP09UAbW+x44zj3zlwWe BWrQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:references:in-reply-to:message-id:date :subject:cc:to:from:dkim-signature:arc-authentication-results; bh=qf+M5sny4qTsp1WhrvpMRRzF0J/RLDLkCnHjX5Hcc0s=; b=SN09356qQdI0S2Wj3ssoUGv9N2w3xj6sEl5ipCOW7WxkJnUbf/Kd9JSqgXIXLEUpba 74Tm4YD9WkLIHQHuoabIkBJBN/6PzuUmjIIegqvzRQIiwqtTsZieosBIN2EHbGEN9E44 bcTn6Zbp5xOZUepy1xli9Qzjup6x9dxYcD8wQh+3ERmEwc7bGniajzOWjtkPe4M0JWq3 pbUv6rneYXKzg1CF5+UO5U6BF3uC/bAGdMUjjE+4FXuFV/dVU0af7KDH6qnGGrvGMlaQ Ae27Z6pXP+SVD2MoUo8LxWBKVuvEb/8/hlvW2+Na/qbxvCU6xovube7l16jJzmfc+lal wA2g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@profitbricks-com.20150623.gappssmtp.com header.s=20150623 header.b=j7eixpY8; spf=pass (google.com: best guess record for domain of stable-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=stable-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id e125si1354818pgc.506.2018.02.23.02.42.36; Fri, 23 Feb 2018 02:42:36 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of stable-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@profitbricks-com.20150623.gappssmtp.com header.s=20150623 header.b=j7eixpY8; spf=pass (google.com: best guess record for domain of stable-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=stable-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750910AbeBWKmf (ORCPT + 10 others); Fri, 23 Feb 2018 05:42:35 -0500 Received: from mail-wr0-f194.google.com ([209.85.128.194]:41572 "EHLO mail-wr0-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751454AbeBWKme (ORCPT ); Fri, 23 Feb 2018 05:42:34 -0500 Received: by mail-wr0-f194.google.com with SMTP id f14so13582914wre.8 for ; Fri, 23 Feb 2018 02:42:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=profitbricks-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id:in-reply-to:references; bh=qf+M5sny4qTsp1WhrvpMRRzF0J/RLDLkCnHjX5Hcc0s=; b=j7eixpY8JmU0cjCYERWDc3oz+ssB467S5+aEeu0v3+s5yXNsGZ9bjYtM6eL5qLoi87 XiVtY/wETv0RCyyc4U773WbLgFhEg3dTLlGiAgru9GWflbQGe9O/5wC2npovtvLJgLNB sSlb5kMlzBnCgtAJ0cpKVZ16pqQ8wsXE/bb2hY3DSCYxXntEUYuUuG9fdm0ABa/dkOEl zHl4XTWMxxrbSj4LeIWHUlR8g88jpl2zbrc+Uds4iid3C1qII/92/Md3J569v5BuUkCD AiyegxDZyoNIolwqQ5fVu91hxwospzhwWyX1HexaTOyWfbWoeWR/AhTRfUHzN9UCYgSb BJFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references; bh=qf+M5sny4qTsp1WhrvpMRRzF0J/RLDLkCnHjX5Hcc0s=; b=OKJIngrpq7pc69mjsqONglnL3nIS33RxbwkDSTi4kbDTq0IZbRn8ZsyN9uSsA7ZjGF hdK5K2G2sImm9uDxoOoAKA7pX3qjJ5QQaLMdK4wn+QhhvQPJeJmY0gyg5ccd/e09xLX5 caOlcw0tFvxR9377gY5GESxIAlQ32kdSKnzTLOqLXZw7cSrfuFWW202X3Ncsfy7LP+du 8ILPT+vM23XV+qCml8SY7J1Kd26wsZVDJl6Afm1NR5j3vl93aOG/af8ePp4iOvNSfPYK +fxwddHTJvqn86QMmWhjyCqPzuNBaXXB5e33gpZyChHYioRogxVKKhoxXzoQ50Dy8mt5 qQxA== X-Gm-Message-State: APf1xPAfe106QcJ630BHjFv8zKTuDl0nTCrQ2XC5J8QfoWeUYL2DG93Q Mowa8hVV0XKROTgDNgBayp8x9g== X-Received: by 10.223.154.165 with SMTP id a34mr1295738wrc.85.1519382553099; Fri, 23 Feb 2018 02:42:33 -0800 (PST) Received: from jinpu-GA-870A-USB3.pb.local ([62.217.45.26]) by smtp.gmail.com with ESMTPSA id d188sm4052653wme.21.2018.02.23.02.42.32 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 23 Feb 2018 02:42:32 -0800 (PST) From: Jack Wang X-Google-Original-From: Jack Wang To: gregkh@linuxfoundation.org, stable@vger.kernel.org Cc: Mark Rutland , Will Deacon , Dan Williams , Thomas Gleixner , linux-arch@vger.kernel.org, Jonathan Corbet , Peter Zijlstra , kernel-hardening@lists.openwall.com, torvalds@linux-foundation.org, alan@linux.intel.com, David Woodhouse , Jack Wang Subject: [stable 4.4 10/29] Documentation: Document array_index_nospec Date: Fri, 23 Feb 2018 11:41:59 +0100 Message-Id: <1519382538-15143-11-git-send-email-jinpu.wangl@profitbricks.com> X-Mailer: git-send-email 2.7.4 In-Reply-To: <1519382538-15143-1-git-send-email-jinpu.wangl@profitbricks.com> References: <1519382538-15143-1-git-send-email-jinpu.wangl@profitbricks.com> Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Mark Rutland (cherry picked from commit f84a56f73dddaeac1dba8045b007f742f61cd2da) Document the rationale and usage of the new array_index_nospec() helper. Signed-off-by: Mark Rutland Signed-off-by: Will Deacon Signed-off-by: Dan Williams Signed-off-by: Thomas Gleixner Reviewed-by: Kees Cook Cc: linux-arch@vger.kernel.org Cc: Jonathan Corbet Cc: Peter Zijlstra Cc: gregkh@linuxfoundation.org Cc: kernel-hardening@lists.openwall.com Cc: torvalds@linux-foundation.org Cc: alan@linux.intel.com Link: https://lkml.kernel.org/r/151727413645.33451.15878817161436755393.stgit@dwillia2-desk3.amr.corp.intel.com Signed-off-by: David Woodhouse Signed-off-by: Greg Kroah-Hartman [jwang: cherry pick to 4.4] Signed-off-by: Jack Wang --- Documentation/speculation.txt | 90 +++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 90 insertions(+) create mode 100644 Documentation/speculation.txt -- 2.7.4 diff --git a/Documentation/speculation.txt b/Documentation/speculation.txt new file mode 100644 index 0000000..e9e6cba --- /dev/null +++ b/Documentation/speculation.txt @@ -0,0 +1,90 @@ +This document explains potential effects of speculation, and how undesirable +effects can be mitigated portably using common APIs. + +=========== +Speculation +=========== + +To improve performance and minimize average latencies, many contemporary CPUs +employ speculative execution techniques such as branch prediction, performing +work which may be discarded at a later stage. + +Typically speculative execution cannot be observed from architectural state, +such as the contents of registers. However, in some cases it is possible to +observe its impact on microarchitectural state, such as the presence or +absence of data in caches. Such state may form side-channels which can be +observed to extract secret information. + +For example, in the presence of branch prediction, it is possible for bounds +checks to be ignored by code which is speculatively executed. Consider the +following code: + + int load_array(int *array, unsigned int index) + { + if (index >= MAX_ARRAY_ELEMS) + return 0; + else + return array[index]; + } + +Which, on arm64, may be compiled to an assembly sequence such as: + + CMP , #MAX_ARRAY_ELEMS + B.LT less + MOV , #0 + RET + less: + LDR , [, ] + RET + +It is possible that a CPU mis-predicts the conditional branch, and +speculatively loads array[index], even if index >= MAX_ARRAY_ELEMS. This +value will subsequently be discarded, but the speculated load may affect +microarchitectural state which can be subsequently measured. + +More complex sequences involving multiple dependent memory accesses may +result in sensitive information being leaked. Consider the following +code, building on the prior example: + + int load_dependent_arrays(int *arr1, int *arr2, int index) + { + int val1, val2, + + val1 = load_array(arr1, index); + val2 = load_array(arr2, val1); + + return val2; + } + +Under speculation, the first call to load_array() may return the value +of an out-of-bounds address, while the second call will influence +microarchitectural state dependent on this value. This may provide an +arbitrary read primitive. + +==================================== +Mitigating speculation side-channels +==================================== + +The kernel provides a generic API to ensure that bounds checks are +respected even under speculation. Architectures which are affected by +speculation-based side-channels are expected to implement these +primitives. + +The array_index_nospec() helper in can be used to +prevent information from being leaked via side-channels. + +A call to array_index_nospec(index, size) returns a sanitized index +value that is bounded to [0, size) even under cpu speculation +conditions. + +This can be used to protect the earlier load_array() example: + + int load_array(int *array, unsigned int index) + { + if (index >= MAX_ARRAY_ELEMS) + return 0; + else { + index = array_index_nospec(index, MAX_ARRAY_ELEMS); + return array[index]; + } + }