On Thu, Jan 10, 2019 at 03:49:27PM +0000, James Greenhalgh wrote: > On Mon, Dec 03, 2018 at 03:55:36AM -0600, Ramana Radhakrishnan wrote: > > For quite sometime the kernel guys, (more specifically Ard) have been > > talking about using a system register (sp_el0) and an offset from that > > for a canary based access. This patchset adds support for a new set of > > command line options similar to how powerpc has done this. > > > > I don't intend to change the defaults in userland, we've discussed this > > for user-land in the past and as far as glibc and userland is concerned > > we stick to the options as currently existing. The system register > > option is really for the kernel to use along with an offset as they > > control their ABI and this is a decision for them to make. > > > > I did consider sticking this all under a mcmodel=kernel-small option but > > thought that would be a bit too aggressive. There is very little error > > checking I can do in terms of the system register being used and really > > the assembler would barf quite quickly in case things go wrong. I've > > managed to rebuild Ard's kernel tree with an additional patch that > > I will send to him. I haven't managed to boot this kernel. > > > > There was an additional question asked about the performance > > characteristics of this but it's a security feature and the kernel > > doesn't have the luxury of a hidden symbol. Further since the kernel > > uses sp_el0 for access everywhere and if they choose to use the same > > register I don't think the performance characteristics would be too bad, > > but that's a decision for the kernel folks to make when taking in the > > feature into the kernel. > > > > I still need to add some tests and documentation in invoke.texi but > > this is at the stage where it would be nice for some other folks > > to look at this. > > > > The difference in code generated is as below. > > > > extern void bar (char *); > > int foo (void) > > { > > char a[100]; > > bar (&a); > > } > > > > $GCC -O2 -fstack-protector-strong vs > > -mstack-protector-guard-reg=sp_el0 -mstack-protector-guard=sysreg > > -mstack-protector-guard-offset=1024 -fstack-protector-strong > > > > > > --- tst.s 2018-12-03 09:46:21.174167443 +0000 > > +++ tst.s.1 2018-12-03 09:46:03.546257203 +0000 > > @@ -15,15 +15,14 @@ > > mov x29, sp > > str x19, [sp, 16] > > .cfi_offset 19, -128 > > - adrp x19, __stack_chk_guard > > - add x19, x19, :lo12:__stack_chk_guard > > - ldr x0, [x19] > > - str x0, [sp, 136] > > - mov x0,0 > > + mrs x19, sp_el0 > > add x0, sp, 32 > > + ldr x1, [x19, 1024] > > + str x1, [sp, 136] > > + mov x1,0 > > bl bar > > ldr x0, [sp, 136] > > - ldr x1, [x19] > > + ldr x1, [x19, 1024] > > eor x1, x0, x1 > > cbnz x1, .L5 > > > > > > > > > > I will be afk tomorrow and day after but this is to elicit some comments > > and for Ard to try this out with his kernel patches. > > > > Thoughts ? > > I didn't see ananswer on list to Ard's questions about the command-line logic.
FWIW: the kernel-side is now merged upstream in 5.0-rc1: http://git.kernel.org/linus/0a1213fa7432 where we ended up checking for the presence of all three options to be on the safe side. Will