public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: "Richard Earnshaw (lists)" <Richard.Earnshaw@arm.com>
To: Richard Biener <richard.guenther@gmail.com>
Cc: GCC Patches <gcc-patches@gcc.gnu.org>
Subject: Re: [PATCH 1/7] Add __builtin_speculation_safe_value
Date: Thu, 26 Jul 2018 13:06:00 -0000	[thread overview]
Message-ID: <da0acd79-c847-07ac-e135-415e8a9c3404@arm.com> (raw)
In-Reply-To: <CAFiYyc0NeM=V8iHTA+q26m1zqXoa=15-agmB84OpnjKGXwXYUg@mail.gmail.com>

On 26/07/18 13:41, Richard Biener wrote:
> On Thu, Jul 26, 2018 at 12:03 PM Richard Earnshaw (lists)
> <Richard.Earnshaw@arm.com> wrote:
>>
>> On 25/07/18 14:47, Richard Biener wrote:
>>> On Wed, Jul 25, 2018 at 2:41 PM Richard Earnshaw (lists)
>>> <Richard.Earnshaw@arm.com> wrote:
>>>>
>>>> On 25/07/18 11:36, Richard Biener wrote:
>>>>> On Wed, Jul 25, 2018 at 11:49 AM Richard Earnshaw (lists)
>>>>> <Richard.Earnshaw@arm.com> wrote:
>>>>>>
>>>>>> On 24/07/18 18:26, Richard Biener wrote:
>>>>>>> On Mon, Jul 9, 2018 at 6:40 PM Richard Earnshaw
>>>>>>> <Richard.Earnshaw@arm.com> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> This patch defines a new intrinsic function
>>>>>>>> __builtin_speculation_safe_value.  A generic default implementation is
>>>>>>>> defined which will attempt to use the backend pattern
>>>>>>>> "speculation_safe_barrier".  If this pattern is not defined, or if it
>>>>>>>> is not available, then the compiler will emit a warning, but
>>>>>>>> compilation will continue.
>>>>>>>>
>>>>>>>> Note that the test spec-barrier-1.c will currently fail on all
>>>>>>>> targets.  This is deliberate, the failure will go away when
>>>>>>>> appropriate action is taken for each target backend.
>>>>>>>
>>>>>>> So given this series is supposed to be backported I question
>>>>>>>
>>>>>>> +rtx
>>>>>>> +default_speculation_safe_value (machine_mode mode ATTRIBUTE_UNUSED,
>>>>>>> +                               rtx result, rtx val,
>>>>>>> +                               rtx failval ATTRIBUTE_UNUSED)
>>>>>>> +{
>>>>>>> +  emit_move_insn (result, val);
>>>>>>> +#ifdef HAVE_speculation_barrier
>>>>>>> +  /* Assume the target knows what it is doing: if it defines a
>>>>>>> +     speculation barrier, but it is not enabled, then assume that one
>>>>>>> +     isn't needed.  */
>>>>>>> +  if (HAVE_speculation_barrier)
>>>>>>> +    emit_insn (gen_speculation_barrier ());
>>>>>>> +
>>>>>>> +#else
>>>>>>> +  warning_at (input_location, 0,
>>>>>>> +             "this target does not define a speculation barrier; "
>>>>>>> +             "your program will still execute correctly, but speculation "
>>>>>>> +             "will not be inhibited");
>>>>>>> +#endif
>>>>>>> +  return result;
>>>>>>>
>>>>>>> which makes all but aarch64 archs warn on __bultin_speculation_safe_value
>>>>>>> uses, even those that do not suffer from Spectre like all those embedded targets
>>>>>>> where implementations usually do not speculate at all.
>>>>>>>
>>>>>>> In fact for those targets the builtin stays in the way of optimization on GIMPLE
>>>>>>> as well so we should fold it away early if neither the target hook is
>>>>>>> implemented
>>>>>>> nor there is a speculation_barrier insn.
>>>>>>>
>>>>>>> So, please make resolve_overloaded_builtin return a no-op on such targets
>>>>>>> which means you can remove the above warning.  Maybe such targets
>>>>>>> shouldn't advertise / initialize the builtins at all?
>>>>>>
>>>>>> I disagree with your approach here.  Why would users not want to know
>>>>>> when the compiler is failing to implement a security feature when it
>>>>>> should?  As for targets that don't need something, they can easily
>>>>>> define the hook as described to suppress the warning.
>>>>>>
>>>>>> Or are you just suggesting moving the warning to resolve overloaded builtin.
>>>>>
>>>>> Well.  You could argue I say we shouldn't even support
>>>>> __builtin_sepeculation_safe_value
>>>>> for archs that do not need it or have it not implemented.  That way users can
>>>>> decide:
>>>>>
>>>>> #if __HAVE_SPECULATION_SAFE_VALUE
>>>>>  ....
>>>>> #else
>>>>> #warning oops // or nothing
>>>>> #endif
>>>>>
>>>>
>>>> So how about removing the predefine of __HAVE_S_S_V when the builtin is
>>>> a nop, but then leaving the warning in if people try to use it anyway?
>>>
>>> Little bit inconsistent but I guess I could live with that.  It still leaves
>>> the question open for how to declare you do not need speculation
>>> barriers at all then.
>>>
>>>>>> Other ports will need to take action, but in general, it can be as
>>>>>> simple as, eg patch 2 or 3 do for the Arm and AArch64 backends - or
>>>>>> simpler still if nothing is needed for that architecture.
>>>>>
>>>>> Then that should be the default.  You might argue we'll only see
>>>>> __builtin_speculation_safe_value uses for things like Firefox which
>>>>> is unlikely built for AVR (just to make an example).  But people
>>>>> are going to test build just on x86 and if they build with -Werror
>>>>> this will break builds on all targets that didn't even get the chance
>>>>> to implement this feature.
>>>>>
>>>>>> There is a test which is intended to fail to targets that have not yet
>>>>>> been patched - I thought that was better than hard-failing the build,
>>>>>> especially given that we want to back-port.
>>>>>>
>>>>>> Port maintainers DO need to decide what to do about speculation, even if
>>>>>> it is explicitly that no mitigation is needed.
>>>>>
>>>>> Agreed.  But I didn't yet see a request for maintainers to decide that?
>>>>>
>>>>
>>>> consider it made, then :-)
>>>
>>> I suspect that drew their attention ;)
>>>
>>> So a different idea would be to produce patches implementing the hook for
>>> each target "empty", CC the target maintainers and hope they quickly
>>> ack if the target doesn't have a speculation problem.  Others then would
>>> get no patch (from you) and thus raise a warning?
>>>
>>> Maybe at least do that for all primary and secondary targets given we do
>>> not want to regress diagnostic-wise (not get new _false_-positives) on
>>> the branch.
>>>
>>>>>>>
>>>>>>> The builtins also have no attributes which mean they are assumed to be
>>>>>>> 1) calling back into the CU via exported functions, 2) possibly throwing
>>>>>>> exceptions, 3) affecting memory state.  I think you at least want
>>>>>>> to use ATTR_NOTHROW_LEAF_LIST.
>>>>>>>
>>>>>>> The builtins are not designed to be optimization or memory barriers as
>>>>>>> far as I can see and should thus be CONST as well.
>>>>>>>
>>>>>>
>>>>>> I think they should be barriers.  They do need to ensure that they can't
>>>>>> be moved past other operations that might depend on the speculation
>>>>>> state.  Consider, for example,
>>>>>
>>>>> That makes eliding them for targets that do not need mitigation even
>>>>> more important.
>>>>>
>>>>>>  ...
>>>>>>  t = untrusted_value;
>>>>>>  ...
>>>>>>  if (t + 5 < limit)
>>>>>>  {
>>>>>>    v = mem[__builtin_speculation_safe_value (untrusted_value)];
>>>>>>    ...
>>>>>>
>>>>>> The compiler must never lift the builtin outside the bounds check as
>>>>>> that is part of the speculation state.
>>>>>
>>>>> OK, so you are relying on the fact that with the current setup GCC has
>>>>> to assume the builtin has side-effects (GCC may not move it to a place that
>>>>> the original location is not post-dominated on).  It doesn't explain
>>>>> why you cannot set ECF_LEAF or why the builtin needs to be
>>>>> considered affecting the memory state.  That is, ECF_NOVOPS
>>>>> or ECF_LOOPING_CONST_OR_PURE (I don't think you can
>>>>> set that manually) would work here, both keep the builtin as
>>>>> having side-effects.
>>>>>
>>>>
>>>> I wish some of this builtin gloop were better documented; at present you
>>>> have to reverse engineer significant amounts of code just to decide
>>>> whether or not you even have to think about whether or not it's relevant...
>>>>
>>>>
>>>>> Btw, if you have an inline function with a pattern like above and
>>>>> you use it multiple times in a row GCC should be able to
>>>>> optimize this?  That is, optimizations like jump-threading also
>>>>> affect the speculation state by modifying the controling
>>>>> conditions.
>>>>
>>>> Ideally, if there's no control flow change, yes.  As soon as you insert
>>>> another branch (in or out) then you might have another speculation path
>>>> to consider.  Not sure how that can easily merging could be done, though.
>>>
>>> The usual case would be
>>>
>>>   if (cond)
>>>    ... _b_s_s_v (x);
>>> <code>
>>>   if (cond)
>>>     ... _b_s_s_v (x);
>>>
>>> where jump-threading might decide to make that to
>>>
>>>   if (cond)
>>>    {
>>>      ... _b_s_s_v (x);
>>>      <copy of code>
>>>      ... _b_s_s_v (x);
>>>    }
>>>
>>> now we might even be able to CSE the 2nd _b_s_s_v (x)
>>> to the first?  That would mean using ECF_CONST|ECF_LOOPING_PURE_OR_CONST
>>> is the best (but we currently have no attribute for the latter).
>>>
>>>>>
>>>>> You didn't answer my question about "what about C++"?
>>>>>
>>>>
>>>> It didn't need a response at this point.  It's a reasonable one, as are
>>>> some of your others...  I was focusing on the the comments that were
>>>> potentially contentious.
>>>>
>>>> BTW, this bit:
>>>>
>>>> +    case BUILT_IN_SPECULATION_SAFE_VALUE_N:
>>>> +      {
>>>> +       int n = speculation_safe_value_resolve_size (function, params);
>>>> +       tree new_function, first_param, result;
>>>> +       enum built_in_function fncode;
>>>> +
>>>> +       if (n == -1)
>>>> +         return error_mark_node;
>>>> +       else if (n == 0)
>>>> +         fncode = (enum built_in_function)((int)orig_code + 1);
>>>> +       else
>>>> +         fncode
>>>> +           = (enum built_in_function)((int)orig_code + exact_log2 (n) + 2);
>>>>
>>>>> resolve_size does that?  Why can that not return the built_in_function
>>>>> itself or BUILT_IN_NONE on error to make that clearer?
>>>>
>>>> is essentially a clone of some existing code that already does it this
>>>> way.  See BUILT_IN_SYNC_LOCK_RELEASE_N etc.  Admittedly, that hunk
>>>> handles multiple origins so would be harder to rewrite as you suggest;
>>>> it just seemed more appropriate to handle the cases similarly.
>>>
>>> Yes, I realized you copied handling from that so I didn't look too closely...
>>>
>>> These days we'd probably use an internal-function and spare us all
>>> the resolving completely (besides a test for validity) ;)
>>>
>>> Richard.
>>>
>>>> R.
>>>>
>>>>> Richard.
>>>>>
>>>>>>
>>>>>>
>>>>>>> BUILT_IN_SPECULATION_SAFE_VALUE_PTR is declared but
>>>>>>> nowhere generated?  Maybe
>>>>>>>
>>>>>>> +    case BUILT_IN_SPECULATION_SAFE_VALUE_N:
>>>>>>> +      {
>>>>>>> +       int n = speculation_safe_value_resolve_size (function, params);
>>>>>>> +       tree new_function, first_param, result;
>>>>>>> +       enum built_in_function fncode;
>>>>>>> +
>>>>>>> +       if (n == -1)
>>>>>>> +         return error_mark_node;
>>>>>>> +       else if (n == 0)
>>>>>>> +         fncode = (enum built_in_function)((int)orig_code + 1);
>>>>>>> +       else
>>>>>>> +         fncode
>>>>>>> +           = (enum built_in_function)((int)orig_code + exact_log2 (n) + 2);
>>>>>>>
>>>>>>> resolve_size does that?  Why can that not return the built_in_function
>>>>>>> itself or BUILT_IN_NONE on error to make that clearer?
>>>>>>>
>>>>>>> Otherwise it looks reasonable but C FE maintainers should comment.
>>>>>>> I miss C++ testcases (or rather testcases should be in c-c++-common).
>>>>>>>
>>>>>>> Richard.
>>>>>>>
>>>>>>>> gcc:
>>>>>>>>         * builtin-types.def (BT_FN_PTR_PTR_VAR): New function type.
>>>>>>>>         (BT_FN_I1_I1_VAR, BT_FN_I2_I2_VAR, BT_FN_I4_I4_VAR): Likewise.
>>>>>>>>         (BT_FN_I8_I8_VAR, BT_FN_I16_I16_VAR): Likewise.
>>>>>>>>         * builtins.def (BUILT_IN_SPECULATION_SAFE_VALUE_N): New builtin.
>>>>>>>>         (BUILT_IN_SPECULATION_SAFE_VALUE_PTR): New internal builtin.
>>>>>>>>         (BUILT_IN_SPECULATION_SAFE_VALUE_1): Likewise.
>>>>>>>>         (BUILT_IN_SPECULATION_SAFE_VALUE_2): Likewise.
>>>>>>>>         (BUILT_IN_SPECULATION_SAFE_VALUE_4): Likewise.
>>>>>>>>         (BUILT_IN_SPECULATION_SAFE_VALUE_8): Likewise.
>>>>>>>>         (BUILT_IN_SPECULATION_SAFE_VALUE_16): Likewise.
>>>>>>>>         * builtins.c (expand_speculation_safe_value): New function.
>>>>>>>>         (expand_builtin): Call it.
>>>>>>>>         * doc/cpp.texi: Document predefine __HAVE_SPECULATION_SAFE_VALUE.
>>>>>>>>         * doc/extend.texi: Document __builtin_speculation_safe_value.
>>>>>>>>         * doc/md.texi: Document "speculation_barrier" pattern.
>>>>>>>>         * doc/tm.texi.in: Pull in TARGET_SPECULATION_SAFE_VALUE.
>>>>>>>>         * doc/tm.texi: Regenerated.
>>>>>>>>         * target.def (speculation_safe_value): New hook.
>>>>>>>>         * targhooks.c (default_speculation_safe_value): New function.
>>>>>>>>         * targhooks.h (default_speculation_safe_value): Add prototype.
>>>>>>>>
>>>>>>>> c-family:
>>>>>>>>         * c-common.c (speculation_safe_resolve_size): New function.
>>>>>>>>         (speculation_safe_resolve_params): New function.
>>>>>>>>         (speculation_safe_resolve_return): New function.
>>>>>>>>         (resolve_overloaded_builtin): Handle __builtin_speculation_safe_value.
>>>>>>>>         * c-cppbuiltin.c (c_cpp_builtins): Add pre-define for
>>>>>>>>         __HAVE_SPECULATION_SAFE_VALUE.
>>>>>>>>
>>>>>>>> testsuite:
>>>>>>>>         * gcc.dg/spec-barrier-1.c: New test.
>>>>>>>>         * gcc.dg/spec-barrier-2.c: New test.
>>>>>>>>         * gcc.dg/spec-barrier-3.c: New test.
>>>>>>>> ---
>>>>>>>>  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/doc/cpp.texi                      |   4 +
>>>>>>>>  gcc/doc/extend.texi                   |  29 +++++++
>>>>>>>>  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 ++++
>>>>>>>>  16 files changed, 424 insertions(+), 1 deletion(-)
>>>>>>>>  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
>>>>>>>>
>>>>>>
>>>>
>>
>> Here's an updated version of this patch, based on these discussions.
>> Notable changes since last time:
>> - __HAVE_SPECULATION_SAFE_VALUE is now only defined if the target has
>> been updated for this feature.
>> - Warnings are only issued if the builtin is used when
>> __HAVE_SPECULATION_SAFE_VALUE is not defined (so the builtin will always
>> generate a workable program, it just might not be protected in this case).
>> - Some of the tests moved to c-c++-common to improve C++ testing.
>> - The builtin is elided early on targets that do not need, or do not
>> provide a specific means to restrict speculative execution.
>>
>> A full bootstrap has completed, but tests are still running.
> 
> Please make the builtins NOVOPS as well by adding
> 
> DEF_ATTR_TREE_LIST (ATTR_NOVOPS_NOTHROW_LEAF_LIST, ATTR_NOVOPS,
> ATTR_NULL, ATTR_NOTHROW_LEAF_LIST)
> 
> to builtin-attrs.def and using that.

This is an optimization right?  If so, can I defer that to a follow-up
patch?  Although the builtin doesn't touch memory, I need think very
carefully about whether or not it is safe to move other memory ops
across it.

> 
> + The default implementation returns true for the first case if the target
> + defines a pattern named @code{speculation_barrier}; for the second case
> + and if the pattern is enabled for the current compilation.
> +@end deftypefn
> 
> I do not understand the last sentence.  I suspect it shold be
> 
> "The default implementation returns false if the target does not define
> a pattern named @code{speculation_barrier}.  Else it returns true
> for the first case and whether the pattern is enabled for the current
> compilation for the second case."

Thanks, I like that wording better than mine.

R.

> 
> Otherwise the middle-end changes look OK to me.  The c-family changes
> need review by a appropriate maintainer still.
> 
> Thanks,
> Richard.
> 
>> gcc:
>>         * builtin-types.def (BT_FN_PTR_PTR_VAR): New function type.
>>         (BT_FN_I1_I1_VAR, BT_FN_I2_I2_VAR, BT_FN_I4_I4_VAR): Likewise.
>>         (BT_FN_I8_I8_VAR, BT_FN_I16_I16_VAR): Likewise.
>>         * builtins.def (BUILT_IN_SPECULATION_SAFE_VALUE_N): New builtin.
>>         (BUILT_IN_SPECULATION_SAFE_VALUE_PTR): New internal builtin.
>>         (BUILT_IN_SPECULATION_SAFE_VALUE_1): Likewise.
>>         (BUILT_IN_SPECULATION_SAFE_VALUE_2): Likewise.
>>         (BUILT_IN_SPECULATION_SAFE_VALUE_4): Likewise.
>>         (BUILT_IN_SPECULATION_SAFE_VALUE_8): Likewise.
>>         (BUILT_IN_SPECULATION_SAFE_VALUE_16): Likewise.
>>         * builtins.c (expand_speculation_safe_value): New function.
>>         (expand_builtin): Call it.
>>         * doc/cpp.texi: Document predefine __HAVE_SPECULATION_SAFE_VALUE.
>>         * doc/extend.texi: Document __builtin_speculation_safe_value.
>>         * doc/md.texi: Document "speculation_barrier" pattern.
>>         * doc/tm.texi.in: Pull in TARGET_SPECULATION_SAFE_VALUE and
>>         TARGET_HAVE_SPECULATION_SAFE_VALUE.
>>         * doc/tm.texi: Regenerated.
>>         * target.def (have_speculation_safe_value, speculation_safe_value): New
>>         hooks.
>>         * targhooks.c (default_have_speculation_safe_value): New function.
>>         (default_speculation_safe_value): New function.
>>         * targhooks.h (default_have_speculation_safe_value): Add prototype.
>>         (default_speculation_safe_value): Add prototype.
>>
>> c-family:
>>         * c-common.c (speculation_safe_resolve_call): New function.
>>         (speculation_safe_resolve_params): New function.
>>         (speculation_safe_resolve_return): New function.
>>         (resolve_overloaded_builtin): Handle __builtin_speculation_safe_value.
>>         * c-cppbuiltin.c (c_cpp_builtins): Add pre-define for
>>         __HAVE_SPECULATION_SAFE_VALUE.
>>
>> testsuite:
>>         * c-c++-common/spec-barrier-1.c: New test.
>>         * c-c++-common/spec-barrier-2.c: New test.
>>         * gcc.dg/spec-barrier-3.c: New test.

  reply	other threads:[~2018-07-26 13:06 UTC|newest]

Thread overview: 82+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-09 16:39 [PATCH 0/7] Mitigation against unsafe data speculation (CVE-2017-5753) Richard Earnshaw
2018-07-09 16:39 ` [PATCH 3/7] AArch64 - add speculation barrier Richard Earnshaw
2018-07-09 16:39 ` [PATCH 7/7] AArch64 - use CSDB based sequences if speculation tracking is enabled Richard Earnshaw
2018-07-09 16:39 ` [PATCH 4/7] AArch64 - Add new option -mtrack-speculation Richard Earnshaw
2018-07-09 16:39 ` [PATCH 1/7] Add __builtin_speculation_safe_value Richard Earnshaw
2018-07-23 14:28   ` Richard Earnshaw (lists)
2018-07-24 17:26   ` Richard Biener
2018-07-25  9:49     ` Richard Earnshaw (lists)
2018-07-25 10:36       ` Richard Biener
2018-07-25 12:41         ` Richard Earnshaw (lists)
2018-07-25 13:47           ` Richard Biener
2018-07-26 10:03             ` Richard Earnshaw (lists)
2018-07-26 12:41               ` Richard Biener
2018-07-26 13:06                 ` Richard Earnshaw (lists) [this message]
2018-07-26 13:13                   ` Richard Biener
2018-07-26 23:34           ` Joseph Myers
2018-07-27  0:46             ` Paul Koning
2018-07-27  8:59               ` Richard Earnshaw (lists)
2018-07-27 10:59                 ` Joseph Myers
2018-07-25 18:03     ` Richard Earnshaw (lists)
2018-07-26  8:42       ` Richard Biener
2018-07-09 16:39 ` [PATCH 6/7] AArch64 - new pass to add conditional-branch speculation tracking Richard Earnshaw
2018-07-11 21:01   ` Jeff Law
2018-07-23 14:33     ` Richard Earnshaw (lists)
2018-07-24 21:31       ` Jeff Law
2018-07-09 16:39 ` [PATCH 5/7] AArch64 - disable CB[N]Z TB[N]Z when tracking speculation Richard Earnshaw
2018-07-09 16:39 ` [PATCH 2/7] Arm - add speculation_barrier pattern Richard Earnshaw
2018-07-09 23:13 ` [PATCH 0/7] Mitigation against unsafe data speculation (CVE-2017-5753) Jeff Law
2018-07-10  8:49   ` Richard Earnshaw (lists)
2018-07-10 13:48     ` Bill Schmidt
2018-07-10 14:14       ` Richard Earnshaw (lists)
2018-07-10 15:44         ` Jeff Law
2018-07-10 15:42     ` Jeff Law
2018-07-10 16:43       ` Richard Earnshaw (lists)
2018-07-11 20:47         ` Jeff Law
2018-07-11 22:31           ` Richard Earnshaw (lists)
2018-07-10  7:19 ` Richard Biener
2018-07-10  8:39   ` Richard Earnshaw (lists)
2018-07-10 10:10     ` Richard Biener
2018-07-10 10:53       ` Richard Earnshaw (lists)
2018-07-10 11:22         ` Richard Biener
2018-07-10 13:43           ` Richard Earnshaw (lists)
2018-07-10 15:56         ` Jeff Law
2018-07-27  9:38 ` [PATCH 00/11] (v2) " Richard Earnshaw
2018-07-27  9:38   ` [PATCH 06/11] AArch64 - new pass to add conditional-branch speculation tracking Richard Earnshaw
2018-07-27  9:38   ` [PATCH 08/11] targhooks - provide an alternative hook for targets that never execute speculatively Richard Earnshaw
2018-07-30 13:17     ` Richard Biener
2018-07-27  9:38   ` [PATCH 09/11] pdp11 - example of a port not needing a speculation barrier Richard Earnshaw
2018-07-27 13:27     ` Paul Koning
2018-07-27 15:19       ` Richard Biener
2018-07-27  9:38   ` [PATCH 05/11] AArch64 - disable CB[N]Z TB[N]Z when tracking speculation Richard Earnshaw
2018-07-27  9:38   ` [PATCH 04/11] AArch64 - Add new option -mtrack-speculation Richard Earnshaw
2018-07-27  9:38   ` [PATCH 03/11] AArch64 - add speculation barrier Richard Earnshaw
2018-07-27  9:38   ` [PATCH 02/11] Arm - add speculation_barrier pattern Richard Earnshaw
2018-08-06 14:01     ` Christophe Lyon
2018-08-06 15:59       ` Richard Earnshaw (lists)
2018-07-27  9:38   ` [PATCH 11/11] rs6000 " Richard Earnshaw
2018-07-31 22:01     ` Bill Schmidt
2018-07-31 23:31       ` Segher Boessenkool
2018-07-27  9:38   ` [PATCH 10/11] x86 " Richard Earnshaw
2018-07-28  8:25     ` Uros Bizjak
2018-07-31 23:15       ` H.J. Lu
2018-07-27  9:38   ` [PATCH 07/11] AArch64 - use CSDB based sequences if speculation tracking is enabled Richard Earnshaw
2018-07-27  9:38   ` [PATCH 01/11] Add __builtin_speculation_safe_value Richard Earnshaw
2018-07-27 12:11     ` Nathan Sidwell
2018-07-27 12:32       ` Richard Earnshaw (lists)
2018-07-27 12:49         ` Nathan Sidwell
2018-07-27 12:53       ` Richard Earnshaw (lists)
2018-07-30 13:16     ` Richard Biener
2018-07-31 19:25       ` H.J. Lu
2018-07-31 20:51         ` Ian Lance Taylor via gcc-patches
2018-08-01  8:50           ` Richard Earnshaw (lists)
2018-08-01  8:54             ` Jakub Jelinek
2018-08-01  9:25               ` Richard Earnshaw (lists)
2018-07-27 19:49   ` [PATCH 00/11] (v2) Mitigation against unsafe data speculation (CVE-2017-5753) John David Anglin
2018-08-02 18:40     ` Jeff Law
2018-08-02 20:19       ` John David Anglin
2018-08-03  9:06         ` Richard Earnshaw (lists)
2018-08-06 21:52           ` John David Anglin
2018-08-07 14:05             ` Richard Earnshaw (lists)
2018-08-07 14:56               ` John David Anglin
2018-08-03 17:26         ` Jeff Law

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=da0acd79-c847-07ac-e135-415e8a9c3404@arm.com \
    --to=richard.earnshaw@arm.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=richard.guenther@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).