[Bug target/115389] New: Invalid ROP hashst offset is emitted when using -mabi=no-altivec

[Bug target/115389] New: Invalid ROP hashst offset is emitted when using -mabi=no-altivec

[bergner at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115389

            Bug ID: 115389
           Summary: Invalid ROP hashst offset is emitted when using
                    -mabi=no-altivec
           Product: gcc
           Version: 15.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: bergner at gcc dot gnu.org
  Target Milestone: ---

We emit a hashst instruction with an invalid offset when compiling with
-mabi=no-altivec.

bergner@ltcd97-lp3:~/ROP$ cat bug.c 
extern void foo (void);
long
bar (void)
{
  foo ();
  return 0;
}
bergner@ltcd97-lp3:~/ROP$ gcc -c -O2 -mcpu=power10 -mrop-protect -mno-vsx
-mno-altivec -mabi=altivec bug.c
bergner@ltcd97-lp3:~/ROP$ gcc -c -O2 -mcpu=power10 -mrop-protect -mno-vsx
-mno-altivec -mabi=no-altivec bug.c 
/tmp/ccSzxbv5.s: Assembler messages:
/tmp/ccSzxbv5.s:15: Error: invalid offset: must be in the range [-512, -8] and
be a multiple of 8
/tmp/ccSzxbv5.s:25: Error: invalid offset: must be in the range [-512, -8] and
be a multiple of 8

The bug is we only compute the ROP hash save slot offset when
TARGET_ALTIVEC_ABI is true. If TARGET_ALTIVEC_ABI is false and we enable ROP
mitigation, then we use the initialized value of zero which is an illegal
offset value for hashst and hashchk.

This has been broken since the rs6000 ROP mitigation code was first added, so
not a regression.

[Bug target/115389] Invalid ROP hashst offset is emitted when using -mabi=no-altivec

[bergner at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115389

Peter Bergner <bergner at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|unassigned at gcc dot gnu.org      |bergner at gcc dot gnu.org
             Target|                            |powerpc64le-linux
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2024-06-07
                 CC|                            |linkw at gcc dot gnu.org,
                   |                            |segher at gcc dot gnu.org
             Status|UNCONFIRMED                 |ASSIGNED

--- Comment #1 from Peter Bergner <bergner at gcc dot gnu.org> ---
I have a patch I'm testing.

[Bug target/115389] Invalid ROP hashst offset is emitted when using -mabi=no-altivec

[segher at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115389

--- Comment #2 from Segher Boessenkool <segher at gcc dot gnu.org> ---
So, what value do we output? And why?

[Bug target/115389] Invalid ROP hashst offset is emitted when using -mabi=no-altivec

[segher at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115389

--- Comment #3 from Segher Boessenkool <segher at gcc dot gnu.org> ---
(In reply to Segher Boessenkool from comment #2)
> So, what value do we output? And why?

It would be nice if the assembler told us, btw :-)

[Bug target/115389] Invalid ROP hashst offset is emitted when using -mabi=no-altivec

[bergner at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115389

--- Comment #4 from Peter Bergner <bergner at gcc dot gnu.org> ---
(In reply to Segher Boessenkool from comment #2)
> So, what value do we output? And why?
The invalid offset is zero, so: hashst r0,0(r1)
As the assembler mentions, the range of valid offsets is [-512,-8] and the
offset must be a multiple of 8.

The "bug" is that we initialize rop_hash_save_offset to zero very early, before
any option processing.  Later, we compute the actual offset, but only in the
case where Altivec is enabled (TARGET_ALTIVEC_ABI is true).  If Altivec is
disabled as in this test case, we end up using rop_hash_save_offset's invalid
initial zero value.

[Bug target/115389] Invalid ROP hashst offset is emitted when using -mabi=no-altivec

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115389

--- Comment #5 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Peter Bergner <bergner@gcc.gnu.org>:

https://gcc.gnu.org/g:c70eea0dba5f223d49c80cfb3e80e87b74330aac

commit r15-1377-gc70eea0dba5f223d49c80cfb3e80e87b74330aac
Author: Peter Bergner <bergner@linux.ibm.com>
Date:   Fri Jun 14 14:36:20 2024 -0500

    rs6000: Compute rop_hash_save_offset for non-Altivec compiles [PR115389]

    We currently only compute the offset for the ROP hash save location in
    the stack frame for Altivec compiles.  For non-Altivec compiles when we
    emit ROP mitigation instructions, we use a default offset of zero which
    corresponds to the backchain save location which will get clobbered on
    any call.  The fix is to compute the ROP hash save location for all
    compiles.

    2024-06-14  Peter Bergner  <bergner@linux.ibm.com>

    gcc/
            PR target/115389
            * config/rs6000/rs6000-logue.cc (rs6000_stack_info): Compute
            rop_hash_save_offset for non-Altivec compiles.

    gcc/testsuite
            PR target/115389
            * gcc.target/powerpc/pr115389.c: New test.

[Bug target/115389] Invalid ROP hashst offset is emitted when using -mabi=no-altivec

[bergner at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115389

--- Comment #6 from Peter Bergner <bergner at gcc dot gnu.org> ---
Fixed on trunk.  I will let it burn-in on trunk for a couple of days before
pushing the backports.