Slight correction:
I am saving Link Register, not stack pointer (although i started as
storing SP, but realized we don't have to do that for ARM because of
LR). Again i don't think we can do it in GIMPLE because there is no
notion of LR in GIMPLE according to my understanding. As the generated
insn show., I am saving the LR in shadow stack variable here.
Thanks,
Arslan
On Wed, May 22, 2019 at 5:37 PM Arslan Khan <arslankhan52@xxxxxxxxx> wrote:
>
> Hi,
> I am a beginner to GCC and am trying to implement safe stack using a
> GCC Plugin for embedded systems. I am using a cross compiler, with GCC
> version:
>
> arm-none-eabi-gcc (GNU Tools for ARM Embedded Processors
> 6-2018-q4-major) 6.3.1 20170620 (release) [ARM/embedded-6-branch
> revision 249437]
>
> The shadow stack is placed on a different RAM chip and is protected
> using software fault isolation (SFI). For SFI i have used a GIMPLE
> pass, but to save the stack pointer in the protected memory i had to
> use an RTL pass, because FWIU GIMPLE has no notion of stack. Anyhow i
> am able to generate insn(s) for saving stack pointer to a , (currently
> there is no indexing, wanted to start simple). Here's the insn
> generated for the prologue:
>
> (insn 21 2 20 2 (set (reg/f:SI 110)
> (symbol_ref:SI ("shadowStack") [flags 0x2])) ./test.c:35 -1
> (nil))
> (insn 20 21 5 2 (set (mem/c:SI (reg/f:SI 110) [0 S4 A32])
> (reg:SI 14 lr)) ./test.c:35 -1
> (nil))
>
> I have tried to copy what cc1 actually generated for an external
> reference. The one thing that is different is that there is no
> information about the variable declaration ins symbol_ref as
> shadowStack is not defined in source and is purely introduced by the
> RTL pass. My plan is to provide shadowStack using a library (which in
> the end version would be an array). I did something similar for GIMPLE
> pass to call functions in an external library and it worked for me.
> However when i run it i get the following error message:
>
> ./test.c: In function 'iowrite_example':
> ./test.c:40:1: error: insn does not satisfy its constraints:
> }
> ^
> (insn 21 2 20 (set (reg/f:SI 110)
> (symbol_ref:SI ("shadowStack") [flags 0x2])) ./test.c:35 172
> {*arm_movsi_insn}
> (nil))
> *** WARNING *** there are active plugins, do not report this as a bug
> unless you can reproduce it without enabling any plugins.
> Event | Plugins
> PLUGIN_ATTRIBUTES | plugin
> PLUGIN_START_UNIT | plugin
> PLUGIN_ALL_IPA_PASSES_START | plugin
> ./test.c:40:1: internal compiler error: in extract_constrain_insn, at
> recog.c:2190
> 0xc8ff4c _fatal_insn(char const*, rtx_def const*, char const*, int, char const*)
> /home/build/toolchain/gcc-arm-none-eabi-6-2017-q2-update/src/gcc/gcc/rtl-error.c:108
> 0xc8ffac _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
> /home/build/toolchain/gcc-arm-none-eabi-6-2017-q2-update/src/gcc/gcc/rtl-error.c:119
> 0xc3b8e0 extract_constrain_insn(rtx_insn*)
> /home/build/toolchain/gcc-arm-none-eabi-6-2017-q2-update/src/gcc/gcc/recog.c:2190
> 0x104dad2 note_invalid_constants
> /home/build/toolchain/gcc-arm-none-eabi-6-2017-q2-update/src/gcc/gcc/config/arm/arm.c:17555
> 0x104fab3 arm_reorg
> /home/build/toolchain/gcc-arm-none-eabi-6-2017-q2-update/src/gcc/gcc/config/arm/arm.c:18413
> 0xc8a5e6 execute
> /home/build/toolchain/gcc-arm-none-eabi-6-2017-q2-update/src/gcc/gcc/reorg.c:3952
>
> FWIU these instruction generated are accepted by some RTL templates
> but the constraints on operands are not satisfied. I tried to debug
> the constrain_operands function, and is turns out we are trying to
> match constraints for arm_movsi_insn pattern. So the constraints were:
>
> constraints[0] const char * 0x1a76cf3 "=rk,r,r,r,rk,m"
> constraints[1] const char * 0x1a76d02 "rk,I,K,j,mi,rk"
>
> My guess was that it should've matched second last alternative but it
> didn't, but i am pretty sure there is nothing wrong with
> constrain_operands, but something is wrong with the way i generated
> the reference. Is there any place i can look for on how to do this
> properly? if required i can share the code here as well for the pass
> (basically i just used gen_rtx_SYMBOL_REF for creating the reference,
> and to be sure there's only one SYMBOL_REF
> (https://gcc.gnu.org/ml/gcc/2003-06/msg02331.html) i save the ref in a
> global variable). Any pointers on what could be wrong in the way i
> generated the reference? Secondly is there any effort going on
> incorporating safe stack with GCC?
>
> Thanks,
> Arslan
