From patchwork Mon Jul 9 16:38:12 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Richard Earnshaw \(lists\)" X-Patchwork-Id: 141466 Delivered-To: patch@linaro.org Received: by 2002:a2e:9754:0:0:0:0:0 with SMTP id f20-v6csp2871425ljj; Mon, 9 Jul 2018 09:39:28 -0700 (PDT) X-Google-Smtp-Source: AAOMgpfZyDOecKwjZBYtwFVlVVMSdoWowz/yYoyTC3R+1YI3J9eJhdBa1m4VoyuExU+GpdP4goYW X-Received: by 2002:a65:498c:: with SMTP id r12-v6mr13713146pgs.112.1531154368277; Mon, 09 Jul 2018 09:39:28 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1531154368; cv=none; d=google.com; s=arc-20160816; b=O7vbgCccezYSoPR6rbKYO9k+nHGdhoYZ8XvrGHhfl9elLkRDYwO8phhNOMKxkkRl6p UngZnJp279DRbdcjClxw0q/QANJjmcgIprghDz0l6DmFtaFECwUF2vkHZQPLzIOC/k9z Yf5eyV8THmLkWUAWT5heOryYfzr5aUBsFNuyITpl2dnVrvlnj6pSM50V/nN6UeGnSWA7 Oc6nQmR5CUkBWrUfezoV7rNMUeFgZI7ohz4nqEnQFBitY1XTiOIiKYK6gbdBaqiV33wB LOKWSQTuwv0osumI+3ltB2HWjd2ZozknPJTK0m6jQjzKrFKprWXk0lA8ZJ4wkWzyiCqH a+cA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=mime-version:message-id:date:subject:cc:to:from:delivered-to:sender :list-help:list-post:list-archive:list-unsubscribe:list-id :precedence:mailing-list:dkim-signature:domainkey-signature :arc-authentication-results; bh=R3b/s0VzVioaE/to71fxEjCjmjL4glgPKVBMckl23XA=; b=HNdb0Y1NNKXKvNcgPvvKDq+Ky62mwMYLxD3N+TSMIYDi6p5RPTnyjtk8QLhOE+cKz7 fxt+e8EpQKI9Vx+71GM2H7cXcybzIVoah6vvIcTsx1u50ij4c6mqxFHRavxi8J8hETS9 /Xvkvo14KvtyDoXE5VOi9DSpqV4h1NM5bCZbEp3imKZYhd0Up3R+Rrm2Q36bv3qG9FDx /2yxXCC0l3r60UeOfujU87bpNCaLE3r+E8LK18u02SJSM0inHckmqagJKredsN5nissC WQXC9NQ5g+u4LcpfLlDzcihp6usREY/bnE8bIgqyiOxUMqpyGoD3tZzEplH/nV5iFeDv 9URA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gcc.gnu.org header.s=default header.b=u03icpT0; spf=pass (google.com: domain of gcc-patches-return-481226-patch=linaro.org@gcc.gnu.org designates 209.132.180.131 as permitted sender) smtp.mailfrom="gcc-patches-return-481226-patch=linaro.org@gcc.gnu.org" Return-Path: Received: from sourceware.org (server1.sourceware.org. [209.132.180.131]) by mx.google.com with ESMTPS id e190-v6si15054890pfa.355.2018.07.09.09.39.27 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 09 Jul 2018 09:39:28 -0700 (PDT) Received-SPF: pass (google.com: domain of gcc-patches-return-481226-patch=linaro.org@gcc.gnu.org designates 209.132.180.131 as permitted sender) client-ip=209.132.180.131; Authentication-Results: mx.google.com; dkim=pass header.i=@gcc.gnu.org header.s=default header.b=u03icpT0; spf=pass (google.com: domain of gcc-patches-return-481226-patch=linaro.org@gcc.gnu.org designates 209.132.180.131 as permitted sender) smtp.mailfrom="gcc-patches-return-481226-patch=linaro.org@gcc.gnu.org" DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:from :to:cc:subject:date:message-id:mime-version:content-type; q=dns; s=default; b=RFz3UmENW0mPfeaTGbYqrKNwLkayBIt6C3uMfj2+9DHDhcWi6a QBHhww9Z7emq6o1i944MUyjUSjm6/Eqv2F+Nz47hAPyYkYC99zp3dYLrTiWRS7Ny zptH/UvYxZm2wUqm2OKSsMf+jnIRBpYoCIIZfZ08xS702yO/Haee86750= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:from :to:cc:subject:date:message-id:mime-version:content-type; s= default; bh=bGv8JmNfP1iyc4KBFJA3Fih/lbE=; b=u03icpT0u+CmO+WAJDdg P5YmfCef/Jwh98AWJanRveLEZQYWFWdH5N8tDrhQWZuq+5lLdRvhFc7vH2hC+RdJ ybV+IgV44ewNuJRp8DuHKT9C86wDIJlrakeQXdi7lvB6I0z2FpxvlRIXRGun/kST //kv6K2rbqYQQxxSLnJ+Lys= Received: (qmail 89699 invoked by alias); 9 Jul 2018 16:39:14 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org Received: (qmail 89685 invoked by uid 89); 9 Jul 2018 16:39:13 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-6.9 required=5.0 tests=BAYES_00, GIT_PATCH_3, SPF_PASS autolearn=ham version=3.3.2 spammy=seven, pause, became, criticism X-HELO: foss.arm.com Received: from usa-sjc-mx-foss1.foss.arm.com (HELO foss.arm.com) (217.140.101.70) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 09 Jul 2018 16:39:12 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 3D17D7A9; Mon, 9 Jul 2018 09:39:10 -0700 (PDT) Received: from e120077-lin.cambridge.arm.com (e120077-lin.cambridge.arm.com [10.2.206.23]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 761E23F589; Mon, 9 Jul 2018 09:39:09 -0700 (PDT) From: Richard Earnshaw To: gcc-patches@gcc.gnu.org Cc: Richard Earnshaw , richard.earnshaw@arm.com Subject: [PATCH 0/7] Mitigation against unsafe data speculation (CVE-2017-5753) Date: Mon, 9 Jul 2018 17:38:12 +0100 Message-Id: <1531154299-28349-1-git-send-email-Richard.Earnshaw@arm.com> MIME-Version: 1.0 The patches I posted earlier this year for mitigating against CVE-2017-5753 (Spectre variant 1) attracted some useful feedback, from which it became obvious that a rethink was needed. This mail, and the following patches attempt to address that feedback and present a new approach to mitigating against this form of attack surface. There were two major issues with the original approach: - The speculation bounds were too tightly constrained - essentially they had to represent and upper and lower bound on a pointer, or a pointer offset. - The speculation constraints could only cover the immediately preceding branch, which often did not fit well with the structure of the existing code. An additional criticism was that the shape of the intrinsic did not fit particularly well with systems that used a single speculation barrier that essentially had to wait until all preceding speculation had to be resolved. To address all of the above, these patches adopt a new approach, based in part on a posting by Chandler Carruth to the LLVM developers list (https://lists.llvm.org/pipermail/llvm-dev/2018-March/122085.html), but which we have extended to deal with inter-function speculation. The patches divide the problem into two halves. The first half is some target-specific code to track the speculation condition through the generated code to provide an internal variable which can tell us whether or not the CPU's control flow speculation matches the data flow calculations. The idea is that the internal variable starts with the value TRUE and if the CPU's control flow speculation ever causes a jump to the wrong block of code the variable becomes false until such time as the incorrect control flow speculation gets unwound. The second half is that a new intrinsic function is introduced that is much simpler than we had before. The basic version of the intrinsic is now simply: T var = __builtin_speculation_safe_value (T unsafe_var); Full details of the syntax can be found in the documentation patch, in patch 1. In summary, when not speculating the intrinsic returns unsafe_var; when speculating then if it can be shown that the speculative flow has diverged from the intended control flow then zero is returned. An optional second argument can be used to return an alternative value to zero. The builtin may cause execution to pause until the speculation state is resolved. There are seven patches in this set, as follows. 1) Introduces the new intrinsic __builtin_sepculation_safe_value. 2) Adds a basic hard barrier implementation for AArch32 (arm) state. 3) Adds a basic hard barrier implementation for AArch64 state. 4) Adds a new command-line option -mtrack-speculation (currently a no-op). 5) Disables CB[N]Z and TB[N]Z when -mtrack-speculation. 6) Adds the new speculation tracking pass for AArch64 7) Uses the new speculation tracking pass to generate CSDB-based barrier sequences I haven't added a speculation-tracking pass for AArch32 at this time. It is possible to do this, but would require quite a lot of rework for the arm backend due to the limited number of registers that are available. Although patch 6 is AArch64 specific, I'd appreciate a review from someone more familiar with the branch edge code than myself. There appear to be a number of tricky issues with more complex edges so I'd like a second opinion on that code in case I've missed an important case. R. Richard Earnshaw (7): Add __builtin_speculation_safe_value Arm - add speculation_barrier pattern AArch64 - add speculation barrier AArch64 - Add new option -mtrack-speculation AArch64 - disable CB[N]Z TB[N]Z when tracking speculation AArch64 - new pass to add conditional-branch speculation tracking AArch64 - use CSDB based sequences if speculation tracking is enabled gcc/builtin-types.def | 6 + gcc/builtins.c | 57 ++++ gcc/builtins.def | 20 ++ gcc/c-family/c-common.c | 143 +++++++++ gcc/c-family/c-cppbuiltin.c | 5 +- gcc/config.gcc | 2 +- gcc/config/aarch64/aarch64-passes.def | 1 + gcc/config/aarch64/aarch64-protos.h | 3 +- gcc/config/aarch64/aarch64-speculation.cc | 494 ++++++++++++++++++++++++++++++ gcc/config/aarch64/aarch64.c | 88 +++++- gcc/config/aarch64/aarch64.md | 140 ++++++++- gcc/config/aarch64/aarch64.opt | 4 + gcc/config/aarch64/iterators.md | 3 + gcc/config/aarch64/t-aarch64 | 10 + gcc/config/arm/arm.md | 21 ++ gcc/config/arm/unspecs.md | 1 + gcc/doc/cpp.texi | 4 + gcc/doc/extend.texi | 29 ++ gcc/doc/invoke.texi | 10 +- gcc/doc/md.texi | 15 + gcc/doc/tm.texi | 20 ++ gcc/doc/tm.texi.in | 2 + gcc/target.def | 23 ++ gcc/targhooks.c | 27 ++ gcc/targhooks.h | 2 + gcc/testsuite/gcc.dg/spec-barrier-1.c | 40 +++ gcc/testsuite/gcc.dg/spec-barrier-2.c | 19 ++ gcc/testsuite/gcc.dg/spec-barrier-3.c | 13 + 28 files changed, 1191 insertions(+), 11 deletions(-) create mode 100644 gcc/config/aarch64/aarch64-speculation.cc create mode 100644 gcc/testsuite/gcc.dg/spec-barrier-1.c create mode 100644 gcc/testsuite/gcc.dg/spec-barrier-2.c create mode 100644 gcc/testsuite/gcc.dg/spec-barrier-3.c