Date: Fri, 25 Sep 2015 09:47:34 -0500 From: Pedro Giffuni <pfg@FreeBSD.org> To: "Chad J. Milios" <milios@ccsys.com> Cc: freeBSD-security@FreeBSD.org Subject: Re: RFC Stack protector strong Message-ID: <56055E86.3090505@FreeBSD.org> In-Reply-To: <89B05640-7733-4FAA-8E2C-3209EC546837@ccsys.com> References: <56043FEF.7040307@FreeBSD.org> <89B05640-7733-4FAA-8E2C-3209EC546837@ccsys.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 09/25/15 04:21, Chad J. Milios wrote: >> On Sep 24, 2015, at 2:24 PM, Pedro Giffuni <pfg@FreeBSD.org> wrote: >> >> (excuse me if you get this message repeated .. I hit the wrong list previously) >> >> Hello; >> >> Our current stack protection is very weak (about 1-2 % coverage). >> Google engineers have developed a new level of protection >> (about 20% coverage) that according to Google and Redhat has >> a negligible impact on performance. >> >> I have opened a code review with a simple update to the default >> setting for our stack protector: >> >> https://reviews.freebsd.org/D3463/ >> >> Sadly I haven't received much feedback. >> >> I have no hurry to commit this but as stated in the review I think it >> is worthwhile. I don’t expect any issue, but it would be better to apply >> this change soonish rather than later so any collateral issues are >> detected and worked out with ample time before 11-Release. >> >> Any objection? If there is no feedback I will just play with other >> things. >> >> Pedro. > > That URL did not work for me (404). I found what you are directing us toward instead at https://reviews.freebsd.org/D3463 > > I like what I'm reading so far, alas I am a nobody. > Well, I am a mechanical engineer, I am not supposed to know about this things either ;). > Could you clarify/elaborate what is meant when you say "coverage" and using these approximate percentages as a metric? Compare and contrast the safestack approach for us, if you would, as well. Please bear with me, I am a C novice and what I know about the magic of compilers could fit on a Post-it Note, the really small kind. While I acknowledge I have no place in this conversation, I think it would draw more people into the discussion if you'd be willing to educate us laypeople a little as attempting to teach often exposes the overlooked gaps in ones own knowledge. > Well, adding the so-called canaries within the executables is something that that involves performance issues. Both GCC and clang implement stack-protector-all but nobody uses it except for very special cases (sshd, perhaps), The default is to only use canaries in a restricted set of functions that are likely to be more vulnerable. A Redhat developer made a nice summary of this and other security measures here: https://youtu.be/T4NadnbfYjY He also includes the metrics for the stack protection. > I understand the difference between a heap and a stack, the process model, the idea of a virtualized memory address space, kernel and user modes of execution and that is about where my expertise ends. I have a vague understanding of how function calls happen, what a system call interface is, an ABI, an ISA, buffer overflows and such as concepts but little experience with the mechanics of any of the aforementioned. I know that things like W^X and MMUs and some mythical "rings" exist to make our lives safer and more productive but as for how they work or if we can trust them, I generally must defer to greater minds whom I then judge by superficial traits such as the size and messiness of their beards and the variety and age of their shirts, both t- and Hawaiian. > > Without simply referring me to a full bookshelf of thousand-page books is there a way people such as myself could become more helpful at assessing such a change? If I enable this on a couple of systems what sorts of breakage or impact should I be looking for? > I wouldn't expect any breakage: the stack protector attempts to prevent buffer overflows from happening. Buffer overflows are errors: nothing good comes from them. I won't make any hard claims but it should be the case that FreeBSD has no buffer overflows and the stack protector will never kick in (famous last words ;)). We haven't ever, and likely will never ever, enable stack-protector-all due to performance issues and if the stronger protector had a serious performance impact it would be disabled. I won't really talk about safestack, I understand it is meant to be much better but I am unaware about how complete it is or the support status on stock FreeBSD. > This is an invitation for anyone to enlighten me, not only the original poster. I'm sure there are a hundred more lurkers afraid to ask. > > Thank you for contributing. > Welcome, Pedro.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?56055E86.3090505>