Date: Wed, 23 Apr 2008 15:17:20 +0200 From: Jeremie Le Hen <jeremie@le-hen.org> To: Antoine Brodin <antoine@FreeBSD.org> Cc: freebsd-arch@freebsd.org Subject: Re: Integration of ProPolice in FreeBSD Message-ID: <20080423131720.GP92168@obiwan.tataz.chchile.org> In-Reply-To: <f19c444a0804200320ifd64f85tbb19bcdbbb657dbb@mail.gmail.com> References: <20080418132749.GB4840@obiwan.tataz.chchile.org> <200804181945.59189.max@love2party.net> <20080418204738.GE4840@obiwan.tataz.chchile.org> <20080419071400.GP73016@server.vk2pj.dyndns.org> <20080419074921.GI4840@obiwan.tataz.chchile.org> <20080420095911.GT5934@hoeg.nl> <f19c444a0804200320ifd64f85tbb19bcdbbb657dbb@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi Antoine,
On Fri, Apr 18, 2008 at 04:37:06PM +0200, Antoine Brodin wrote:
> Last time I looked at your patch, there was a problem when using
> -fstack-protector-all instead of -fstack-protector:
> when you compile lib/csu/*, gnu/lib/csu/*, or
> src/lib/libc/sys/stack_protector.c with this flag, there is a kind of
> chicken/egg problem and you end up with an unusable world.
> That said, it would be great to be able to compile world with SSP when
> an option is set in src.conf.
You were right. I had a chance to test it this weekend. Thank you for
pointing this out.
On Sun, Apr 20, 2008 at 12:20:34PM +0200, Antoine Brodin wrote:
> On Sun, Apr 20, 2008 at 11:59 AM, Ed Schouten <ed@80386.nl> wrote:
> > Couldn't __stack_chk_init() be implemented like this:
> >
> > | static void
> > | __stack_chk_init(void *dummy __unused)
> > | {
> > | arc4rand(__stack_chk_guard, sizeof(__stack_chk_guard), 0);
> > | }
>
> You can't do this because arc4rand will be protected and the guard
> won't be same when you return from arc4rand.
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.
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?
Thank you for your advices.
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?20080423131720.GP92168>