On Wed, May 29, 2019 at 11:50 PM Arslan Khan <arslankha...@gmail.com> wrote:
>
> Are you suggesting that i insert an extern at source level? Wouldn't
> that decrease the usability of the safe stack drastically? Currently
> all user has to do is provide an address where we intend to place
> shadow stack, but if he has to place extern symbols in all using files
> that would be cumbersome.
> Besides that even i do that, is there a symbol table maintained by GCC
> that i can use to access this in an RTL pass?
I'm not suggesting to declare it at source level but you have to create
and assemble it, see how tree-profile.c uses build_decl.
Richard.
> Thanks,
> Arslan
>
> On Wed, May 29, 2019 at 3:17 AM Richard Biener
> <richard.guent...@gmail.com> wrote:
> >
> > On Tue, May 28, 2019 at 1:01 AM Arslan Khan <arslankha...@gmail.com> 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 Link Register in the protected memory i had to
> > > use an RTL pass, because FWIU GIMPLE has no notion of registers. Anyhow i
> > > am able to generate insn(s) for saving stack pointer to a symbol
> > > "shadowStack", created by RTL pass (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? Lastly please tell me if this
> > > question belongs here or gcc-help list? i tried gcc-help but it looks
> > > like most question there are for GCC users not developers.
> >
> > You should probably add and assemble the global external variable
> > early in the compilation.
> >
> > > Thanks,
> > > Arslan
