Integration of ProPolice in FreeBSD

[Jeremie Le Hen]

Hi John,

On Wed, Apr 23, 2008 at 09:34:42AM -0400, John Baldwin wrote:
> 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().

Ok thanks for the info.

> > 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().

Sorry, I should have mentionned that I've already skimmed over gcc info
page and then asked on #gcc on FreeNode for such an atttribute, but
there isn't:

% 22:16 < Guilt> there are a lot of problems in enabling/disabling
% fstack-protector in the mid of the program
% 22:16 < Guilt> one is that specs for libssp are taken from the driver
% program
% 22:17 < Guilt> not the compiler (cc1) and it's not possible to
% arbitrarily enable/disable those

Ultimately those functions should be moved into separate compilation
units.  Maybe the current layout is sufficient, I don't know.  Would you
please give me some hint about the functions that must not be protected?
Maybe all the MD stuff?

Thank you very much.
Best regards,
-- 
Jeremie Le Hen
< jeremie at le-hen dot org >< ttz at chchile dot org >