From patchwork Thu Mar 1 15:27:44 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Sasha Levin X-Patchwork-Id: 130311 Delivered-To: patch@linaro.org Received: by 10.80.172.228 with SMTP id x91csp2953532edc; Thu, 1 Mar 2018 07:39:32 -0800 (PST) X-Google-Smtp-Source: AG47ELv9lm2RmalrKyosuvvhOGj5zXud169xGg0O+s26PPz7unr6/1mv1Oe7MLdqHmGtabkOo740 X-Received: by 2002:a17:902:7485:: with SMTP id h5-v6mr2355285pll.236.1519918772311; Thu, 01 Mar 2018 07:39:32 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1519918772; cv=none; d=google.com; s=arc-20160816; b=pIXgbc357Gk2cV/aDBZR0mMjt67DdPKEBROzXzTZSJ7LOR8dFeYqiwDDOFhrIbOKit rk6wNzNo1vxeLnFO+5ZFcDNaJGNVYiH8u0fGf9Dz7LVJeRXtQst8uRP1JJsNBuQWz2HZ fxoCq0kH6bB9TNClLDooh+VRmABbN6A01FfWAHUuKYNI0YQkOAtlyu1u6Xthxtcz8tzd 1ZK0CADFaoCmSDSWJH+Le4BoDMohr298PGCjyqMCoYvd7huNjvEwZMFA6+aRCCbczTfF 7vJkhhBIez/trkC+QdXhfDc8TnXkm3iMM4GodX0Un3ro+HDwL+bVApjgEvZZitEk3myp C6Rw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:content-transfer-encoding :spamdiagnosticmetadata:spamdiagnosticoutput:content-language :accept-language:in-reply-to:references:message-id:date:thread-index :thread-topic:subject:cc:to:from:dkim-signature :arc-authentication-results; bh=/AA2ElGrXae2FA6W5/BOTkM+HPCZtpAvxM7p76pnOAY=; b=cPINlJP9wfKtlers/vsu5pXmPCSqb+V7C4oHoGMYVy5a/RL9iVnSvFdfLbfKrL+Ero HmnvT04ebE/KRZ8nridZz0z+3zrYS7RYmW8Yf3Y1Tindyh1dqvEueqgCzTMC3hDUzpVp dYgvOLkTEcRKqNZSdAPBVDuzOA83wyP9RUNPL9cd2+E/oHeTY9s6ppm3o31RR6LgizeO E16Ni1wv9jtRSz2PI2A5Mr0KeXlPqzRDqu9Px02wSoH2UYa6uVYnEY3B3hMjZhS/dSHH iplJIB9I31AFH4qGPSi6iCysMuOcxLGbQ7WMg5q8EOUZgoavJFl85fZiTMf/4oHs/DmV C6cQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@microsoft.com header.s=selector1 header.b=YRukaY8W; 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; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=microsoft.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id l18si2606550pgn.103.2018.03.01.07.39.32; Thu, 01 Mar 2018 07:39:32 -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=@microsoft.com header.s=selector1 header.b=YRukaY8W; 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; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=microsoft.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1032574AbeCAPj1 (ORCPT + 10 others); Thu, 1 Mar 2018 10:39:27 -0500 Received: from mail-bn3nam01on0096.outbound.protection.outlook.com ([104.47.33.96]:5876 "EHLO NAM01-BN3-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1032257AbeCAPjT (ORCPT ); Thu, 1 Mar 2018 10:39:19 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=/AA2ElGrXae2FA6W5/BOTkM+HPCZtpAvxM7p76pnOAY=; b=YRukaY8W5f4EVLurVtFgOka7FmaCt4SwwXR8auNErlh9A6SyQtSfVW+jBXF2lHe1X8slZOhUieJy8oKyKyaZEd205pUh8A/kpup/URfUjHB4WEd9hmnyunVutEYwhkTzsxnbTLZex4wOKxKd3/COttaCpsigC7c7uHyA8gvkGpE= Received: from DM5PR2101MB1032.namprd21.prod.outlook.com (52.132.128.13) by DM5PR2101MB1093.namprd21.prod.outlook.com (52.132.130.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.567.2; Thu, 1 Mar 2018 15:39:17 +0000 Received: from DM5PR2101MB1032.namprd21.prod.outlook.com ([fe80::8063:c68a:b210:7446]) by DM5PR2101MB1032.namprd21.prod.outlook.com ([fe80::8063:c68a:b210:7446%2]) with mapi id 15.20.0567.006; Thu, 1 Mar 2018 15:39:17 +0000 From: Sasha Levin To: "stable@vger.kernel.org" , "stable-commits@vger.kernel.org" CC: Mark Rutland , Will Deacon , Dan Williams , Thomas Gleixner , Sasha Levin Subject: [added to the 4.1 stable tree] Documentation: Document array_index_nospec Thread-Topic: [added to the 4.1 stable tree] Documentation: Document array_index_nospec Thread-Index: AQHTsXHYu1CR0uuxxUm/JRDz/1T/YA== Date: Thu, 1 Mar 2018 15:27:44 +0000 Message-ID: <20180301152116.1486-492-alexander.levin@microsoft.com> References: <20180301152116.1486-1-alexander.levin@microsoft.com> In-Reply-To: <20180301152116.1486-1-alexander.levin@microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [52.168.54.252] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR2101MB1093; 7:okSn/Q6BgssGc96KYYzx2HbbNaxJDDEq4vJq2l2B9oiT7G2XtSQolv2TVUsJdaDNWTZ2jgIWRtwHk1DaZuRqv8cAZ+BdF3rEtUz6atAyL6JK1m8tVQf+/9dQNilbfjJUGOL6KtlLhKSispw/kxmxFEWTmnkRcF9g0aW3oRVN/isILIX9t6Yybfejl4c9sz73gpKpTXgtpYHv6kd20MxUxEtFykI2eIVmPVdcDxtxlohpPwp2G41PMtXo4LdY/fwd x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 106a717f-dcf5-4d91-3031-08d57f8a97d1 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(48565401081)(5600026)(4604075)(3008032)(2017052603307)(7193020); SRVR:DM5PR2101MB1093; x-ms-traffictypediagnostic: DM5PR2101MB1093: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(180628864354917)(89211679590171)(9452136761055)(42068640409301)(228905959029699); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(61425038)(6040501)(2401047)(5005006)(8121501046)(3002001)(93006095)(93001095)(10201501046)(3231220)(944501229)(52105095)(6055026)(61426038)(61427038)(6041288)(20161123560045)(20161123558120)(20161123564045)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:DM5PR2101MB1093; BCL:0; PCL:0; RULEID:; SRVR:DM5PR2101MB1093; x-forefront-prvs: 05986C03E0 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(396003)(346002)(39380400002)(39860400002)(376002)(189003)(199004)(3660700001)(5250100002)(2501003)(105586002)(86612001)(4326008)(106356001)(36756003)(6486002)(6436002)(6506007)(3846002)(1076002)(76176011)(6116002)(97736004)(3280700002)(5660300001)(8676002)(81156014)(81166006)(2900100001)(10090500001)(8936002)(2906002)(2950100002)(6666003)(107886003)(22452003)(86362001)(99286004)(25786009)(54906003)(110136005)(316002)(6306002)(26005)(53936002)(72206003)(6512007)(478600001)(10290500003)(7736002)(305945005)(186003)(102836004)(14454004)(6346003)(66066001)(966005)(68736007)(22906009); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR2101MB1093; H:DM5PR2101MB1032.namprd21.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=Alexander.Levin@microsoft.com; x-microsoft-antispam-message-info: STCcTFmRNLJcbxFsGX1mLvDJ4xlRM9dUa6k1s7G5RqV6nJ3lLeugS+nRUhABKbfgshtpWnGQ9cjvjVTexJ+4/RM2SHF5B2TOkWA8yGlUeupUwa17rMRAm+OsVpe02T15zEbbebqsKO73nTe2Er/+dh6X5FiRVmKd/uUZXamBVN0= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 106a717f-dcf5-4d91-3031-08d57f8a97d1 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Mar 2018 15:27:44.2281 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR2101MB1093 Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Mark Rutland This patch has been added to the 4.1 stable tree. If you have any objections, please let us know. -- 2.14.1 =============== [ Upstream 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: Sasha Levin --- Documentation/speculation.txt | 90 +++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 90 insertions(+) create mode 100644 Documentation/speculation.txt diff --git a/Documentation/speculation.txt b/Documentation/speculation.txt new file mode 100644 index 000000000000..e9e6cbae2841 --- /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]; + } + }