From owner-freebsd-toolchain@FreeBSD.ORG Fri Nov 18 14:37:35 2011 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 9D6791065670; Fri, 18 Nov 2011 14:37:35 +0000 (UTC) Date: Fri, 18 Nov 2011 14:37:35 +0000 From: Alexander Best To: freebsd-toolchain@freebsd.org Message-ID: <20111118143735.GA46352@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Subject: -fstack-protector vs. -fstack-protector-all X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Nov 2011 14:37:35 -0000 hi there, what are the reasons for using -fstack-protector instead of -fstack-protector-all in sys/conf/kern.mk? cheers. alex From owner-freebsd-toolchain@FreeBSD.ORG Sat Nov 19 11:24:18 2011 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 56F8F106566B; Sat, 19 Nov 2011 11:24:18 +0000 (UTC) Date: Sat, 19 Nov 2011 11:24:18 +0000 From: Alexander Best To: freebsd-toolchain@freebsd.org Message-ID: <20111119112418.GA42980@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Subject: 'make installkernel' succeeding on read-only fs? X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Nov 2011 11:24:18 -0000 hi there, just stumbled upon this little detail: 1) have "/" mounted read-only 2) 'make buildkernel' 3) 'make installkernel && echo "success"' -> this will fail 4) 'mount -uw /' 5) 'make installkernel && echo "success"' -> this will succeed 6) 'mount -ur /' 7) 'make installkernel && echo "success"' -> this will succeed. why? cheers. alex From owner-freebsd-toolchain@FreeBSD.ORG Sat Nov 19 11:47:05 2011 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7C5E3106564A; Sat, 19 Nov 2011 11:47:05 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id 4019E8FC12; Sat, 19 Nov 2011 11:47:05 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:30d7:12c8:99d6:295e] (unknown [IPv6:2001:7b8:3a7:0:30d7:12c8:99d6:295e]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 7332C5C37; Sat, 19 Nov 2011 12:47:04 +0100 (CET) Message-ID: <4EC7973E.9010108@FreeBSD.org> Date: Sat, 19 Nov 2011 12:47:10 +0100 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Alexander Best References: <20111118143735.GA46352@freebsd.org> In-Reply-To: <20111118143735.GA46352@freebsd.org> X-Enigmail-Version: 1.3.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-toolchain@freebsd.org Subject: Re: -fstack-protector vs. -fstack-protector-all X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Nov 2011 11:47:05 -0000 On 2011-11-18 15:37, Alexander Best wrote: > what are the reasons for using -fstack-protector instead of > -fstack-protector-all in sys/conf/kern.mk? My guess would be one or more of the following: - The price in performance is too high - The gain in security is too low - Some routines in the kernel are run before the whole stack protection infrastructure is in place, ergo they can't have stack protection - There might be other problems with -fstack-protector-all, lib/libc/Makefile says: # XXX For now, we don't allow libc to be compiled with # -fstack-protector-all because it breaks rtld. We may want to make a librtld # in the future to circumvent this. SSP_CFLAGS:= ${SSP_CFLAGS:S/^-fstack-protector-all$/-fstack-protector/} From owner-freebsd-toolchain@FreeBSD.ORG Sat Nov 19 23:53:46 2011 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 50F6D106566C; Sat, 19 Nov 2011 23:53:46 +0000 (UTC) Date: Sat, 19 Nov 2011 23:53:46 +0000 From: Alexander Best To: Dimitry Andric Message-ID: <20111119235346.GA57138@freebsd.org> References: <20111108002556.GA91218@freebsd.org> <4EB8E07B.5070908@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4EB8E07B.5070908@FreeBSD.org> Cc: freebsd-toolchain@freebsd.org Subject: Re: CPUTYPE=native handling X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Nov 2011 23:53:46 -0000 On Tue Nov 8 11, Dimitry Andric wrote: > On 2011-11-08 01:25, Alexander Best wrote: > > i've seen dozens of issues, where people set CPUTYPE=native. although this > > works in a lot of cases, it doesn't in others. why don't we simply add > > something like > > > > . if ${CPUTYPE} == "native" > > . error "bla" > > . endif > > > > in share/mk/bsd.cpu.mk for now? or at least for the archs, where "native" is > > known to cause problems. > > What does this solve? Don't you think it is better to try to fix the > actual problems? Some people like being able to optimize for their > specific CPU, however much you can shoot yourself in the foot with it. just wanted to report that i found an issue with CPUTYPE "native". simply do the following on amd64 (i tested this on ref9-amd64.freebsd.org): make.conf: CPUTYPE ?= native CFLAGS = -O2 -pipe -fno-strict-aliasing -funroll-loops -fno-builtin KERNCONF = GENERIC now 'make buildworld' and enjoy the signal 11. ;) setting CPUTYPE to nocona or commenting it out lets 'mak buildworld' succeed. cheers. alex there's a problem report for this already: http://www.freebsd.org/cgi/query-pr.cgi?pr=gnu/149712 > > I haven't seen any consistent bug reports yet, just a lot of complaints > that indicate a rather high probability of PEBKAC. > > And just to counter the nay-saying, I compiled a number of boxes with > clang -march=native (mostly of the Xeon/i7 variant) and I haven't seen > any problems at all.