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