Message ID | 1532684275-13041-1-git-send-email-Richard.Earnshaw@arm.com |
---|---|
Headers | show |
Series | (v2) Mitigation against unsafe data speculation (CVE-2017-5753) | expand |
On 2018-07-27 5:37 AM, Richard Earnshaw wrote: > Port Maintainers: You need to decide what action is required for your > port to handle speculative execution, even if that action is to use > the trivial no-speculation on this architecture. You must also > consider whether or not a furture implementation of your architecture > might need to deal with this in making that decision. On hppa, I think we should go with the hook that assumes there is no speculative execution. Nominally, there is branch prediction and speculative execution; but the spectre test program was not able to successfully access memory on my rp3440. As far as I know, the details of speculative execution on PA-RISC are not public. Jeff would know best. Dave -- John David Anglin dave.anglin@bell.net
On 07/27/2018 01:48 PM, John David Anglin wrote: > On 2018-07-27 5:37 AM, Richard Earnshaw wrote: >> Port Maintainers: You need to decide what action is required for your >> port to handle speculative execution, even if that action is to use >> the trivial no-speculation on this architecture. You must also >> consider whether or not a furture implementation of your architecture >> might need to deal with this in making that decision. > On hppa, I think we should go with the hook that assumes there is no > speculative execution. > > Nominally, there is branch prediction and speculative execution; but the > spectre test program > was not able to successfully access memory on my rp3440. > > As far as I know, the details of speculative execution on PA-RISC are > not public. Jeff would know It's been eons. I think there's enough building blocks on the PA to mount a spectre v1 attack. They've got branch prediction with varying degress of speculative execution, caches and user accessable cycle timers. There's varying degrees of out of order execution all the way back in the PA7xxx processors (hit-under-miss) to full o-o-o execution in the PA8xxx series (including the PA8900 that's in the rp3440). I suspect that given enough time we could figure out why the test didn't indicate spectre v1 vulnerability on your system and twiddle it, but given it's a dead processor, I doubt it's worth the effort. jeff
On 2018-08-02 2:40 PM, Jeff Law wrote: > It's been eons. I think there's enough building blocks on the PA to > mount a spectre v1 attack. They've got branch prediction with varying > degress of speculative execution, caches and user accessable cycle timers. Yes. > > There's varying degrees of out of order execution all the way back in > the PA7xxx processors (hit-under-miss) to full o-o-o execution in the > PA8xxx series (including the PA8900 that's in the rp3440). However, as far as I know, loads and stores are always ordered. > > I suspect that given enough time we could figure out why the test didn't > indicate spectre v1 vulnerability on your system and twiddle it, but > given it's a dead processor, I doubt it's worth the effort. Spectre output looks like this: dave@mx3210:~/meltdown$ ./spectre Reading 40 bytes: Reading at malicious_x = 0xffffef10... Unclear: 0xFE='?' score=999 (second best: 0xFC score=999) Reading at malicious_x = 0xffffef11... Unclear: 0xFC='?' score=999 (second best: 0xFB score=999) Reading at malicious_x = 0xffffef12... Unclear: 0xFE='?' score=999 (second best: 0xFC score=999) I don't think there's a suitable barrier. The sync instruction seems like overkill. So, I'm going to install attached change after testing is complete. Dave -- John David Anglin dave.anglin@bell.net Index: config/pa/pa.c =================================================================== --- config/pa/pa.c (revision 263228) +++ config/pa/pa.c (working copy) @@ -428,6 +428,9 @@ #undef TARGET_STARTING_FRAME_OFFSET #define TARGET_STARTING_FRAME_OFFSET pa_starting_frame_offset +#undef TARGET_HAVE_SPECULATION_SAFE_VALUE +#define TARGET_HAVE_SPECULATION_SAFE_VALUE speculation_safe_value_not_needed + struct gcc_target targetm = TARGET_INITIALIZER; /* Parse the -mfixed-range= option string. */
On 02/08/18 21:19, John David Anglin wrote: > On 2018-08-02 2:40 PM, Jeff Law wrote: >> It's been eons. I think there's enough building blocks on the PA to >> mount a spectre v1 attack. They've got branch prediction with varying >> degress of speculative execution, caches and user accessable cycle >> timers. > Yes. >> >> There's varying degrees of out of order execution all the way back in >> the PA7xxx processors (hit-under-miss) to full o-o-o execution in the >> PA8xxx series (including the PA8900 that's in the rp3440). > However, as far as I know, loads and stores are always ordered. >> >> I suspect that given enough time we could figure out why the test didn't >> indicate spectre v1 vulnerability on your system and twiddle it, but >> given it's a dead processor, I doubt it's worth the effort. > Spectre output looks like this: > dave@mx3210:~/meltdown$ ./spectre > Reading 40 bytes: > Reading at malicious_x = 0xffffef10... Unclear: 0xFE='?' score=999 > (second best: 0xFC score=999) > Reading at malicious_x = 0xffffef11... Unclear: 0xFC='?' score=999 > (second best: 0xFB score=999) > Reading at malicious_x = 0xffffef12... Unclear: 0xFE='?' score=999 > (second best: 0xFC score=999) > > I don't think there's a suitable barrier. The sync instruction seems > like overkill. > > So, I'm going to install attached change after testing is complete. > It's your call as port maintainers. I've created a PR for each unfixed architecture. Please can you commit the patch against that so that I can track things for back-porting. Thanks, R. > Dave > > > pa-spectre.d > > > Index: config/pa/pa.c > =================================================================== > --- config/pa/pa.c (revision 263228) > +++ config/pa/pa.c (working copy) > @@ -428,6 +428,9 @@ > #undef TARGET_STARTING_FRAME_OFFSET > #define TARGET_STARTING_FRAME_OFFSET pa_starting_frame_offset > > +#undef TARGET_HAVE_SPECULATION_SAFE_VALUE > +#define TARGET_HAVE_SPECULATION_SAFE_VALUE speculation_safe_value_not_needed > + > struct gcc_target targetm = TARGET_INITIALIZER; > > /* Parse the -mfixed-range= option string. */ >
On 08/02/2018 02:19 PM, John David Anglin wrote: > On 2018-08-02 2:40 PM, Jeff Law wrote: >> It's been eons. I think there's enough building blocks on the PA to >> mount a spectre v1 attack. They've got branch prediction with varying >> degress of speculative execution, caches and user accessable cycle >> timers. > Yes. >> >> There's varying degrees of out of order execution all the way back in >> the PA7xxx processors (hit-under-miss) to full o-o-o execution in the >> PA8xxx series (including the PA8900 that's in the rp3440). > However, as far as I know, loads and stores are always ordered. I'm pretty sure that's not true on PA8000 class machines: You can get the details here: http://web.archive.org/web/20040214092531/http://www.cpus.hp.com/technical_references/advperf.shtml It describes in reasonable detail how the load/store reorder buffer and the address reorder buffer works as well as the tag checking to detect when a speculative load was executed and its results had to be thrown away due to a store-to-load dependency check in the ARB. But again, given the state of the target, I'm not at all concerned about mitigating spectre v1. Jeff
On 2018-08-03 5:06 AM, Richard Earnshaw (lists) wrote: >> I don't think there's a suitable barrier. The sync instruction seems >> like overkill. >> >> So, I'm going to install attached change after testing is complete. >> > It's your call as port maintainers. I committed the attached change after testing on hppa-unknown-linux-gnu. Dave -- John David Anglin dave.anglin@bell.net 2018-08-06 John David Anglin <danglin@gcc.gnu.org> PR target/86807 * config/pa/pa.c (TARGET_HAVE_SPECULATION_SAFE_VALUE): Define to speculation_safe_value_not_needed. Index: config/pa/pa.c =================================================================== --- config/pa/pa.c (revision 263228) +++ config/pa/pa.c (working copy) @@ -428,6 +428,9 @@ #undef TARGET_STARTING_FRAME_OFFSET #define TARGET_STARTING_FRAME_OFFSET pa_starting_frame_offset +#undef TARGET_HAVE_SPECULATION_SAFE_VALUE +#define TARGET_HAVE_SPECULATION_SAFE_VALUE speculation_safe_value_not_needed + struct gcc_target targetm = TARGET_INITIALIZER; /* Parse the -mfixed-range= option string. */
On 06/08/18 22:52, John David Anglin wrote: > On 2018-08-03 5:06 AM, Richard Earnshaw (lists) wrote: >>> I don't think there's a suitable barrier. The sync instruction seems >>> like overkill. >>> >>> So, I'm going to install attached change after testing is complete. >>> >> It's your call as port maintainers. > I committed the attached change after testing on hppa-unknown-linux-gnu. > Thanks. Wrong PR, though: that was for the SPU port. The hppa PR is 86785. R. > Dave > > > pa-spectre.d > > > 2018-08-06 John David Anglin <danglin@gcc.gnu.org> > > PR target/86807 > * config/pa/pa.c (TARGET_HAVE_SPECULATION_SAFE_VALUE): > Define to speculation_safe_value_not_needed. > > Index: config/pa/pa.c > =================================================================== > --- config/pa/pa.c (revision 263228) > +++ config/pa/pa.c (working copy) > @@ -428,6 +428,9 @@ > #undef TARGET_STARTING_FRAME_OFFSET > #define TARGET_STARTING_FRAME_OFFSET pa_starting_frame_offset > > +#undef TARGET_HAVE_SPECULATION_SAFE_VALUE > +#define TARGET_HAVE_SPECULATION_SAFE_VALUE speculation_safe_value_not_needed > + > struct gcc_target targetm = TARGET_INITIALIZER; > > /* Parse the -mfixed-range= option string. */ >
On 2018-08-07 10:05 AM, Richard Earnshaw (lists) wrote:
> Thanks. Wrong PR, though: that was for the SPU port. The hppa PR is 86785.
Oops, sorry for extra work.
Dave
--
John David Anglin dave.anglin@bell.net