Integration of ProPolice in FreeBSD
John Baldwin
jhb at freebsd.org
Wed Apr 23 14:03:36 UTC 2008
On Wednesday 23 April 2008 09:17:20 am Jeremie Le Hen wrote:
> This limitation also exists in the kernel. Currently, the kernel canary
> is initialized with:
>
> +/* SI_SUB_EVENTHANDLER is right after SI_SUB_LOCK, used by arc4rand()
> init. */ +SYSINIT(stack_chk, SI_SUB_EVENTHANDLER, SI_ORDER_ANY,
> __stack_chk_init, NULL);
>
> Luckily it seems that for now there is no function on the calling path
> to __stack_chk_init() that GCC deem useful to protect with
> stack-smashing protection. There is nothing that will prevent this to
> occur because of a careless change in the future though.
>
> So obviously, using -fstack-protector-all will break the kernel too.
>
> FWIW, it is easier to handle this in NetBSD as the canary is initialized
> in main(). Nonetheless I suppose it may arise if main() happens to
> return.
mi_startup() is what runs the sysinit's and is the equivalent of main().
> I'm not sure what is the best way to handle this. Should I write special
> rules for those files with
> ${CFLAGS:S/^-fstack-protector-all$/-fstack-protector/g}
> or simply document that building the system with -fstack-protector-all
> is not supported?
Does GCC provide an attribute that can be applied to a function to disable
stack protection? We could explicitly disable it for the few functions
(mi_startup(), initi386(), etc.) on the call path to mi_startup().
--
John Baldwin
More information about the freebsd-arch
mailing list