Date: Wed, 23 Apr 2008 16:33:56 +0200 From: Jeremie Le Hen <jeremie@le-hen.org> To: John Baldwin <jhb@freebsd.org> Cc: Antoine Brodin <antoine@freebsd.org>, freebsd-arch@freebsd.org Subject: Re: Integration of ProPolice in FreeBSD Message-ID: <20080423143356.GQ92168@obiwan.tataz.chchile.org> In-Reply-To: <200804230934.42497.jhb@freebsd.org> References: <20080418132749.GB4840@obiwan.tataz.chchile.org> <f19c444a0804200320ifd64f85tbb19bcdbbb657dbb@mail.gmail.com> <20080423131720.GP92168@obiwan.tataz.chchile.org> <200804230934.42497.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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 >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080423143356.GQ92168>