[gentoo-dev] Re: gcc 4.3.2 security updates
On Sunday 11 January 2009 01.06.45 Ciaran McCreesh wrote: > On Sat, 10 Jan 2009 18:03:17 -0600 > > Ryan Hill wrote: > > I'm really hoping this isn't a stable candidate. :P > > Is an earlier gcc 4.3 a stable candidate, or have those plans been > abandoned? > > (I'm wondering whether it's worth the pain of dealing with 4.1's lack > of tr1 regex support...) We will get more bugs if we enable FORTIFY_SOURCE for the stable canididet of gcc 4.3 like /usr/include/bits/fcntl2.h:51: error: call to '__open_missing_mode' declared with attribute error: open with O_CREAT in second argument needs 3 arguments GLIBC won't even compile with it. /Zorry
Re: [gentoo-dev] Re: gcc 4.3.2 security updates
On Sunday 11 January 2009 04.26.00 Mike Frysinger wrote: > On Saturday 10 January 2009 19:03:17 Ryan Hill wrote: > > On Sat, 10 Jan 2009 16:22:50 -0500 Mike Frysinger wrote: > > > not to be out done, gcc-4.3.2-r3 will include changes like some other > > > distros are now carrying: > > > - the -Wformat-security flag is enabled by default > > > - the -D_FORTIFY_SOURCE=2 flag is enabled by default > > > > > > if you dont want this stuff, you can use the flag > > > -Wno-format-security and the flag -U_FORTIFY_SOURCE respectively > > > > I'm really hoping this isn't a stable candidate. :P > > gcc-4.3.2-r0 is still the stable candidate. nothing has changed. > -mike Any patches ready? /Zorry
Re: [gentoo-dev] Re: gcc 4.3.2 security updates
On Sunday 11 January 2009 09.39.08 Mike Frysinger wrote: > On Saturday 10 January 2009 23:52:15 Magnus Granberg wrote: > > On Sunday 11 January 2009 04.26.00 Mike Frysinger wrote: > > > On Saturday 10 January 2009 19:03:17 Ryan Hill wrote: > > > > On Sat, 10 Jan 2009 16:22:50 -0500 Mike Frysinger wrote: > > > > > not to be out done, gcc-4.3.2-r3 will include changes like some > > > > > other distros are now carrying: > > > > > - the -Wformat-security flag is enabled by default > > > > > - the -D_FORTIFY_SOURCE=2 flag is enabled by default > > > > > > > > > > if you dont want this stuff, you can use the flag > > > > > -Wno-format-security and the flag -U_FORTIFY_SOURCE respectively > > > > > > > > I'm really hoping this isn't a stable candidate. :P > > > > > > gcc-4.3.2-r0 is still the stable candidate. nothing has changed. > > > > Any patches ready? > > patches for what ? > -mike For the FORTIFY and Wformat thing but i will see when it hit the tree.
Re: [gentoo-dev] 17.0 profiles
fredag 6 oktober 2017 kl. 14:23:49 CEST skrev Andreas K. Huettel: > Hi all, > > Since gcc-6 stabilization is drawing closer, I'm going to prepare the > remaining 17.0 profiles (right now they only exist for amd64). > > Meaning... copy profiles/default/linux/*/13.0 to profiles/default/linux/*/ > 17.0, and edit it so it inherits 17.0 instead of 13.0. > > Plan is to add the new profiles as "exp" to profiles.desc when arches are > cc'ed to the gcc-6 stablereq, and switch them to the same status (exp/dev/ > stable) as the corresponding 13.0 profiles when an arch stabilizes gcc-6. > > Packages that don't build with >=gcc-6 will be masked in the 17.0 profiles. > > I'll only take care of the default/linux/* profiles. Everyone else > (hardened, BSD, musl, ...) please feel free to contact me for advice. > > Cheers, > Andreas Hardened will move to features/hardened as selinux have and be addad as sub profile to the 17.0 profiles. Amd64 will go first. /Magnus G.
Re: [gentoo-dev] RFC: news item for the 17.0 profiles
måndag 9 oktober 2017 kl. 22:58:22 CEST skrev Andreas K. Huettel: > = > Title: New 17.0 profiles in the Gentoo repository > Author: Andreas K. Hüttel > Posted: xxx > Revision: 1 > News-Item-Format: 2.0 > Display-If-Installed: >=sys-devel/gcc-6.4.0 > > We have just added a new set of profiles with release version 17.0 > to the Gentoo repository. These bring tree changes: > 1) The default C++ language version for applications is now C++14. >This change is mostly relevant to Gentoo developers. It also >means, however, that compilers earlier than GCC 6 are masked >and not supported for use as a system compiler anymore. Feel >free to unmask them if you need them for specific applications. > 2) Where supported, GCC will now build position-independent >executables (PIE) by default. This improves the overall >security fingerprint. The switch from non-PIE to PIE binaries, >however, requires some steps by users, as detailed below. > 3) Hardened profiles will be moved to the 17.0 profile as sub profile. > Please consider switching from your current 13.0 profile to the > corresponding 17.0 profile soon after GCC-6.4.0 has been > stabilized on your architecture. The 13.0 profiles will be deprecated > and removed in the near future. > > Switching involves the following steps: > If not already done, > * Use gcc-config to select gcc-6.4.0 or later as system compiler > * Re-source /etc/profile: > . /etc/profile > * Re-emerge libtool > Then, > * Select the new profile with eselect > * Re-emerge, in this sequence, gcc, binutils, and glibc > emerge -1 sys-devel/gcc:6.4.0 > emerge -1 sys-devel/binutils > emerge -1 sys-libs/glibc > * Rebuild your entire system > emerge -e world > > If you do not follow these steps you may get spurious build > failures when the linker tries unsuccessfully to combine non-PIE > and PIE code. > =
Re: [gentoo-dev] stability of 17.0 hardened profile
onsdag 14 februari 2018 kl. 19:44:13 CET skrev Paweł Hajdan, Jr.: > I was looking into the new 17.0 profiles (nice work!), and noticed the > hardened one is marked as dev. I'm somewhat concerned about switching to > that on my laptop (I'm currently using hardened/linux/amd64). > > Is there something I can do to help move the profile to stable? > > Alternatively, is there a different profile recommended for hardened? > > # eselect profile list > ... > [12] default/linux/amd64/17.0 (stable) > [13] default/linux/amd64/17.0/selinux (dev) > [14] default/linux/amd64/17.0/hardened (dev) > [15] default/linux/amd64/17.0/hardened/selinux (dev) > [16] default/linux/amd64/17.0/desktop (stable) > [17] default/linux/amd64/17.0/desktop/gnome (stable) > [18] default/linux/amd64/17.0/desktop/gnome/systemd (stable) > [19] default/linux/amd64/17.0/desktop/plasma (stable) > [20] default/linux/amd64/17.0/desktop/plasma/systemd (stable) > [21] default/linux/amd64/17.0/developer (stable) > [22] default/linux/amd64/17.0/no-multilib (stable) > [23] default/linux/amd64/17.0/no-multilib/hardened (dev) > [24] default/linux/amd64/17.0/no-multilib/hardened/selinux (dev) > [25] default/linux/amd64/17.0/systemd (stable) > [26] default/linux/amd64/17.0/x32 (dev) > ... > [40] hardened/linux/amd64 (stable) * > > Paweł Have mark the Hardened 17.0 as stable now /Magnus
[gentoo-dev] Uptade for toolchain.eclass and Gcc 6.2
Hi
The patch add use flag for pch, so it can be disable.
We add support to use the configure options for pie and ssp
instead of the -D* hack for it.
The hardened use flag will add or remove some compile options as,
-fstrict_overflow will be turn of for -O2 and higher,
-fstack-check is added as default and
we change from -fstack-protect-strong to -fstack-protect-all.
It will not be any hardenedno* and vanilla options in gcc-config.
That is all change we bee do for hardened.
Ssp will be enable as default when i fix that it can be disable with -nostdlib.
For the pie part it will be option to enable even for default user in the
amd64 arch when the major bugs i fixed for it. See the tracker https://
bugs.gentoo.org/show_bug.cgi?id=582688 any bugs should be upstreamed for we
just configure gcc to default to pie/ssp as default that gcc 6.x has support
for.
/Magnus G.
Gentoo Hardened Lead Dev
--- gentoogit/gentoo/eclass/toolchain.eclass 2016-08-03 16:01:50.401048177 +0200
+++ hardened/hardened-dev/eclass/toolchain.eclass 2016-08-27 19:22:41.599786421 +0200
@@ -1,4 +1,4 @@
-# Copyright 1999-2015 Gentoo Foundation
+# Copyright 1999-2016 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Id$
@@ -154,7 +154,7 @@ if [[ ${PN} != "kgcc64" && ${PN} != gcc-
tc_version_is_at_least 4.8 && IUSE+=" graphite" IUSE_DEF+=( sanitize )
tc_version_is_at_least 4.9 && IUSE+=" cilk +vtv"
tc_version_is_at_least 5.0 && IUSE+=" jit mpx"
- tc_version_is_at_least 6.0 && IUSE+=" pie +ssp"
+ tc_version_is_at_least 6.0 && IUSE+=" pie ssp +pch"
fi
IUSE+=" ${IUSE_DEF[*]/#/+}"
@@ -626,6 +626,50 @@ do_gcc_PIE_patches() {
# configure to build with the hardened GCC specs as the default
make_gcc_hard() {
+
+ local gcc_hard_flags=""
+ # Gcc >= 6.X we can use configurations options to turn pie/ssp on as default
+ if tc_version_is_at_least 6.0 ; then
+ if use pie ; then
+ einfo "Updating gcc to use automatic PIE building ..."
+ fi
+ if use ssp ; then
+ einfo "Updating gcc to use automatic SSP building ..."
+ fi
+ if use hardened ; then
+ # Will add some optimatizion as default.
+ gcc_hard_flags+=" -DEXTRA_OPTIONS"
+ # rebrand to make bug reports easier
+ BRANDING_GCC_PKGVERSION=${BRANDING_GCC_PKGVERSION/Gentoo/Gentoo Hardened}
+ fi
+ else
+ if use hardened ; then
+ # rebrand to make bug reports easier
+ BRANDING_GCC_PKGVERSION=${BRANDING_GCC_PKGVERSION/Gentoo/Gentoo Hardened}
+ if hardened_gcc_works ; then
+einfo "Updating gcc to use automatic PIE + SSP building ..."
+gcc_hard_flags+=" -DEFAULT_PIE_SSP"
+ elif hardened_gcc_works pie ; then
+einfo "Updating gcc to use automatic PIE building ..."
+ewarn "SSP has not been enabled by default"
+gcc_hard_flags+=" -DEFAULT_PIE"
+ elif hardened_gcc_works ssp ; then
+einfo "Updating gcc to use automatic SSP building ..."
+ewarn "PIE has not been enabled by default"
+gcc_hard_flags+=" -DEFAULT_SSP"
+ else
+# do nothing if hardened isn't supported, but don't die either
+ewarn "hardened is not supported for this arch in this gcc version"
+return 0
+ fi
+ else
+ if hardened_gcc_works ssp ; then
+einfo "Updating gcc to use automatic SSP building ..."
+gcc_hard_flags+=" -DEFAULT_SSP"
+ fi
+ fi
+ fi
+
# we want to be able to control the pie patch logic via something other
# than ALL_CFLAGS...
sed -e '/^ALL_CFLAGS/iHARD_CFLAGS = ' \
@@ -634,36 +678,8 @@ make_gcc_hard() {
# Need to add HARD_CFLAGS to ALL_CXXFLAGS on >= 4.7
if tc_version_is_at_least 4.7 ; then
sed -e '/^ALL_CXXFLAGS/iHARD_CFLAGS = ' \
--e 's|^ALL_CXXFLAGS = |ALL_CXXFLAGS = $(HARD_CFLAGS) |' \
--i "${S}"/gcc/Makefile.in
- fi
-
- # defaults to enable for all toolchains
- local gcc_hard_flags=""
- if use hardened ; then
- if hardened_gcc_works ; then
- einfo "Updating gcc to use automatic PIE + SSP building ..."
- gcc_hard_flags+=" -DEFAULT_PIE_SSP"
- elif hardened_gcc_works pie ; then
- einfo "Updating gcc to use automatic PIE building ..."
- ewarn "SSP has not been enabled by default"
- gcc_hard_flags+=" -DEFAULT_PIE"
- elif hardened_gcc_works ssp ; then
- einfo "Updating gcc to use automatic SSP building ..."
- ewarn "PIE has not been enabled by default"
- gcc_hard_flags+=" -DEFAULT_SSP"
- else
- # do nothing if hardened isn't supported, but don't die either
- ewarn "hardened is not supported for this arch in this gcc version"
- return 0
- fi
- # rebrand to make bug reports easier
- BRANDING_GCC_PKGVERSION=${BRANDING_GCC_PKGVERSION/Gentoo/Gentoo Hardened}
- else
- if hardened_gcc_works ssp ; then
- einfo "Updating gcc to use automatic SSP building ..."
- gcc_hard_flags+=" -DEFAULT_SSP"
- fi
+ -e 's|^ALL_CXXFLAGS = |ALL_CXXFLAGS = $(HARD_CFLAGS) |' \
+ -i "${S}"/gcc/Makefile.in
fi
sed -i \
@@ -899,6 +915,11 @@ toolchain_src_configure() {
confgcc+=( --enable-libstdcxx-time )
fi
+ # Support to dis
Re: [gentoo-dev] Tinderboxing efforts in Gentoo
fredag 2 december 2016 kl. 23:32:37 CET skrev Daniel Campbell: > On 12/02/2016 06:09 AM, Michael Mol wrote: > > On Friday, December 02, 2016 02:10:27 PM Michał Górny wrote: > >> Hi, everyone. > >> > >> I've heard multiple times about various tinderbox projects being > >> started by individuals in Gentoo. In fact, so many different projects > >> that I've forgotten who was working on most of them. > >> > >> I know that Toralf is doing tinderboxing for most of the stuff. > >> What other projects do we have there? What is their status? > >> > >> Is there anything we could try to integrate with pull requests to get > >> a better testing? > > > > If there's a mostly-turnkey VM I can run to contribute to Tinderboxing, I > > have one or two systems I could benefit from some heat from over the > > winter. It's that or bring out the electric space heater. Was talking > > with my wife about mining Doge on one of them last night... > > I second that. I have a hexcore CPU and 16 GB of RAM, most of which I > don't use unless I'm compiling. If there's a guide that can get me up > and running with a VM within an hour or so, I'd be more than willing to > pitch in some cycles. > > mgorny mentioned PRs, however... are such efforts moot if I don't have a > GitHub account? I run tinderbox-cluster [1] with 4-7 WM's but it have been down for some time now. The web frontend need alot of work. It still miss bugreporting and build requests and the grafic need work to. It use django. /Magnus [1] https://wiki.gentoo.org/wiki/Project:Tinderbox-cluster
[gentoo-dev] Gcc 6 and Gcc 5 update
Hi Gcc 6.X update: Gcc 6.3 will soon get released in one or two weeks on that the pie use flag will get unmasked and gcj will be masked for java is removed in gcc 7 Package that fail with the pie flag needed to get fixed upstream for we are not the only dist that use it now days. Gcc 5.X update Time to start fixing bugs [1] for it is time to mark it stable. it will be 5.4 or 5.5. Any more bugs that need fixing that not in the gcc 5 porting? [1] https://bugs.gentoo.org/show_bug.cgi?id=536984
Re: [gentoo-dev] Pre-GLEP for review: mix-in profiles
måndag 23 januari 2017 kl. 13:56:02 CET skrev Rich Freeman: > On Mon, Jan 23, 2017 at 4:23 AM, Michał Górny wrote: > > I've written a short proposal that aims to provide basic infrastructure > > for defining mix-in profiles in Gentoo. I've tried to keep it simple, > > and backwards compatible. The main goal is to be able to start defining > > some mix-ins without having to reinvent the whole profile tree. > > Would it actually make sense to reinvent more of the profile tree > while we're at it? So, have a few categories of mixins like kernel, > arch, and some category that covers really invasive stuff like > hardened/libc/etc? > i think it would make sense to reinvent/split it up to a few categories/mixins like base arch abi libc kernel init/udev desktop server security > Those might be 1-of-n selections. > > Then we could have the fluff that sits on top and just set some rules > about what they can do. > > Part of me wonders if some of this could also fit in with the use of > virtuals (think foo-meta virtuals but bigger). A virtual can of > course pull in USE dependencies, and a lot of other stuff. We could > have convenience virtuals that all the profiles pull in by default but > which gets stuff like openssh out of @system. > > I'm only suggesting the last bit to the extent where we see tie-ins to > improve the initial mix-in implementation. A lot of that is probably > an expansion in scope, and to that extent I'm not suggesting that it > needs to be addressed. I just want to think about it broadly at first > to make sure we're not missing something.
Re: [gentoo-dev] Re: Can we have process names and stdout / stderr indication to more efficiently parse build logs?
tisdag 03 september 2013 22.41.14 skrev Alan McKinnon: > I *do* like colorized text on my terminal, but I do believe we ought to > keep defaults sane - the minimum that could possibly work. Everything > extra should be optional What about NOCOLOR="false" in make.conf see man make.conf for more info. /Magnus
Re: [gentoo-dev] Re: Improve the security of the default profile
onsdag 11 september 2013 00.07.29 skrev Ryan Hill: > On Tue, 10 Sep 2013 18:41:34 -0400 > > Richard Yao wrote: > > A few thoughts: > > > > 1. The kernel expects -fno-stack-protector to be the default. What will > > the effect be on kernel configuration once -fstack-protector is the > > default? > The kernel has supported building with -fstack-protector since 2.6.19, (at > least on x86/x86-64). It's controlled by CONFIG_CC_STACKPROTECTOR and if > it's disabled then -fno-stack-protector is explicitly added to the command > line. On Hardened we disable -fstack-protector* when building kernel and it is done with some gcc spec rules that we patch gcc with and it have been working long before gcc 4.X versions. It can be turned on with the kernel config option CONFIG_CC_STACKPROTECTOR. /Magnus signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: Improve the security of the default profile
onsdag 11 september 2013 04.49.55 skrev Duncan: > (Tho jer points out that the parisc arch, among others, won't work with > that flag at all, and warns to that effect. So I guess the patch will > etiher be ifdeffed not to apply on such archs or will be conditionally > applied in the first place. The former is I believe preferred as > conditional patching is considered subpar.) > We only enable -fstack-protector* if the arch is set in SSP_STABLE or SSP_UCLIBC_STABLE in the ebuild. For uclibc and ssp it need to be newer then .32 and have nptl enable. /Magnus
Re: [gentoo-dev] Re: Improve the security of the default profile
måndag 09 september 2013 21.00.12 skrev Ryan Hill: > On Mon, 9 Sep 2013 08:21:35 -0400 > > Rich Freeman wrote: > > On Sun, Sep 8, 2013 at 8:06 PM, Ryan Hill wrote: > > > So does anyone have any objections to making -fstack-protector the > > > default? > > > Now is the time to speak up. > > > > So, in this world of all-or-nothing we want people who realize that > > 100% protection might not be possible to raise an objection so that we > > end up with 0% protection instead? > > No, all I've heard so far is support and wanted to give anyone with an > opposing viewpoint a chance to speak up. I support it, but if there are > any problems we might run into it's best we know about them beforehand, no? > I wasn't looking for a reason to veto it. > > > Why not just do the sensible thing (IMHO) and make it a default, and > > then if it doesn't work for an individual package deal with it on an > > individual basis? We already encourage maintainers to try to get > > custom CFLAGS to work when practical, but when not practical we filter > > them. I don't see stack protection as any different. If there is a > > fix, then fix it, and if not, then disable it. I don't see a lack of > > stack-protection as a reason to keep something out of the tree. > > Rich, that's exactly what I'm saying. > > We have to make an effort to fix things properly, like we do with any > supported feature. That's something I see as one of the key strengths of > this group we have. Obviously there are cases where a fix isn't possible > (glibc and gcc itself are prime examples) and we need to disable it. > That's fine. But we need to discourage people sweeping problems under the > rug because they're inconvenient, especially when those problems may > indicate security issues. > > I'm just trying to set proper expectations - that this change may break > people's packages, and they may have to do some work to find out why and how > to fix it. I don't like creating more work for people, so I want to be > sure there is consensus on this first. So far it sounds like there is. I did build most of the packages (~14000 packages) in tree when we move from gcc 3.X to 4.X with stack protection and some packages didn't work but we fix it or added work work arounds to them. So in short most of the package work is allready done. /Magnus signature.asc Description: This is a digitally signed message part.
[gentoo-dev] [PATCH] To enable ssp default in Gcc the toolchain.eclass need some changes.
Hi
Some time ago we discussed that we should enable stack smashing
(-fstack-protector) by default. So we opened a bug to track this [1].
The affected Gcc version will be 4.8.2 and newer. Only amd64, x86, mips, ppc,
ppc64 and arm will be affected by this change.
You can turn off ssp by using the nossp USE flag or by adding
-fno-stack-protector to the CFLAGS and/or CXXFLAGS. We are using the same
patch as Debian/Ubuntu but with some Gentoo fixes.
The patch will move the sed for the HARD_CFLAGS, ALLCFLAGS and
ALLCXXFLAGS from do_gcc_PIE_patches() to make_gcc_hard(). We will
make_gcc_hard() the default for all Gcc versions 4.8 and newer, and turn
it on or off with hardened_gcc_works() that will make some sanity checks.
/Magnus
2013-12-31 Magnus Granberg
# 484714
We Add -fstack-protector as default
--- a/eclass/toolchain.eclass 2013-12-30 21:21:05.431832881 +0100
+++ b/eclass/toolchain.eclass 2013-12-31 11:34:00.720993536 +0100
@@ -473,7 +473,9 @@ toolchain_src_prepare() {
do_gcc_PIE_patches
epatch_user
- use hardened && make_gcc_hard
+ if ( tc_version_is_at_least 4.8 || use hardened ) && ! use vanilla ; then
+ make_gcc_hard
+ fi
# install the libstdc++ python into the right location
# http://gcc.gnu.org/PR51368
@@ -606,6 +608,12 @@ do_gcc_PIE_patches() {
epatch "${WORKDIR}"/piepatch/def
fi
+ BRANDING_GCC_PKGVERSION="${BRANDING_GCC_PKGVERSION}, pie-${PIE_VER}"
+}
+
+# configure to build with the hardened GCC specs as the default
+make_gcc_hard() {
+
# we want to be able to control the pie patch logic via something other
# than ALL_CFLAGS...
sed -e '/^ALL_CFLAGS/iHARD_CFLAGS = ' \
@@ -618,38 +626,38 @@ do_gcc_PIE_patches() {
-i "${S}"/gcc/Makefile.in
fi
- BRANDING_GCC_PKGVERSION="${BRANDING_GCC_PKGVERSION}, pie-${PIE_VER}"
-}
-
-# configure to build with the hardened GCC specs as the default
-make_gcc_hard() {
- # defaults to enable for all hardened toolchains
- local gcc_hard_flags="-DEFAULT_RELRO -DEFAULT_BIND_NOW"
-
- if hardened_gcc_works ; then
- einfo "Updating gcc to use automatic PIE + SSP building ..."
- gcc_hard_flags+=" -DEFAULT_PIE_SSP"
- elif hardened_gcc_works pie ; then
- einfo "Updating gcc to use automatic PIE building ..."
- ewarn "SSP has not been enabled by default"
- gcc_hard_flags+=" -DEFAULT_PIE"
- elif hardened_gcc_works ssp ; then
- einfo "Updating gcc to use automatic SSP building ..."
- ewarn "PIE has not been enabled by default"
- gcc_hard_flags+=" -DEFAULT_SSP"
+ # defaults to enable for all toolchains
+ local gcc_hard_flags=""
+ if use hardened ; then
+ if hardened_gcc_works ; then
+ einfo "Updating gcc to use automatic PIE + SSP building ..."
+ gcc_hard_flags+=" -DEFAULT_PIE_SSP"
+ elif hardened_gcc_works pie ; then
+ einfo "Updating gcc to use automatic PIE building ..."
+ ewarn "SSP has not been enabled by default"
+ gcc_hard_flags+=" -DEFAULT_PIE"
+ elif hardened_gcc_works ssp ; then
+ einfo "Updating gcc to use automatic SSP building ..."
+ ewarn "PIE has not been enabled by default"
+ gcc_hard_flags+=" -DEFAULT_SSP"
+ else
+ # do nothing if hardened is't supported, but don't die either
+ ewarn "hardened is not supported for this arch in this gcc version"
+ return 0
+ fi
+ # rebrand to make bug reports easier
+ BRANDING_GCC_PKGVERSION=${BRANDING_GCC_PKGVERSION/Gentoo/Gentoo Hardened}
else
- # do nothing if hardened isnt supported, but dont die either
- ewarn "hardened is not supported for this arch in this gcc version"
- ebeep
- return 0
+ if hardened_gcc_works ssp ; then
+ einfo "Updating gcc to use automatic SSP building ..."
+ gcc_hard_flags+=" -DEFAULT_SSP"
+ fi
fi
sed -i \
-e "/^HARD_CFLAGS = /s|=|= ${gcc_hard_flags} |" \
"${S}"/gcc/Makefile.in || die
- # rebrand to make bug reports easier
- BRANDING_GCC_PKGVERSION=${BRANDING_GCC_PKGVERSION/Gentoo/Gentoo Hardened}
}
# This is a historical wart. The original Gentoo/amd64 port used:
Re: [gentoo-dev] [PATCH] To enable ssp default in Gcc the toolchain.eclass need some changes.
torsdag 09 januari 2014 22.57.09 skrev Pacho Ramos: > El jue, 09-01-2014 a las 21:58 +0100, Magnus Granberg escribió: > > Hi > > > > Some time ago we discussed that we should enable stack smashing > > (-fstack-protector) by default. So we opened a bug to track this [1]. > > The affected Gcc version will be 4.8.2 and newer. Only amd64, x86, mips, > > ppc, ppc64 and arm will be affected by this change. > > > > You can turn off ssp by using the nossp USE flag or by adding > > -fno-stack-protector to the CFLAGS and/or CXXFLAGS. We are using the same > > patch as Debian/Ubuntu but with some Gentoo fixes. > > > > The patch will move the sed for the HARD_CFLAGS, ALLCFLAGS and > > ALLCXXFLAGS from do_gcc_PIE_patches() to make_gcc_hard(). We will > > make_gcc_hard() the default for all Gcc versions 4.8 and newer, and turn > > it on or off with hardened_gcc_works() that will make some sanity checks. > > > > /Magnus > > What are the advantages of disabling SSP to deserve that "special" > handling via USE flag or easily disabling it appending the flag? > > Thanks a lot for the info :) If you want Gcc not to build stuff with ssp as default you turn on the nossp flag and rebuild Gcc. /Magnus
Re: [gentoo-dev] Re: [PATCH] To enable ssp default in Gcc the toolchain.eclass need some changes.
torsdag 09 januari 2014 23.18.28 skrev Ryan Hill: > On Thu, 09 Jan 2014 21:58:46 +0100 > > Magnus Granberg wrote: > > Some time ago we discussed that we should enable stack smashing > > (-fstack-protector) by default. So we opened a bug to track this [1]. > > The affected Gcc version will be 4.8.2 and newer. Only amd64, x86, mips, > > ppc, ppc64 and arm will be affected by this change. > > > > You can turn off ssp by using the nossp USE flag or by adding > > -fno-stack-protector to the CFLAGS and/or CXXFLAGS. We are using the same > > patch as Debian/Ubuntu but with some Gentoo fixes. > > > > The patch will move the sed for the HARD_CFLAGS, ALLCFLAGS and > > ALLCXXFLAGS from do_gcc_PIE_patches() to make_gcc_hard(). We will > > make_gcc_hard() the default for all Gcc versions 4.8 and newer, and turn > > it on or off with hardened_gcc_works() that will make some sanity checks. > > I went ahead and spun a new patchset for the compiler-side stuff if anyone > wants to start playing around. > > - apply the eclass patch from bug #484714 (the one attached to Magnus' email > wouldn't apply for me but maybe my mailer mangled it) > - in gcc-4.8.2.ebuild do: > > -PATCH_VER="1.3" > +PATCH_VER="1.4-ssptest" > > -PIE_VER="0.5.8" > +PIE_VER="0.5.9-ssptest" > > BTW Magnus, thanks for doing this. Hi Have patched toolchain.eclass with the patch and with your change. Updated 4.8.2 updated with the needed changes and commit it. The use hardened && gcc-specs-ssp && append-cflags $(test-flags-CC -fno-stack- protector) in glibc's common.eblit is fixed to. So default ssp is out in the tree :) /Magnus signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: [PATCH] To enable ssp default in Gcc the toolchain.eclass need some changes.
torsdag 09 januari 2014 17.56.56 skrev Ryan Hill: > On Thu, 09 Jan 2014 21:58:46 +0100 > > Magnus Granberg wrote: > > - use hardened && make_gcc_hard > > + if ( tc_version_is_at_least 4.8 || use hardened ) && ! use vanilla ; > > then > > s/4.8/4.8.2 > > Or should we wait until the next release (4.8.3 or 4.9.0)? I think I'd > prefer it but I don't have a good reason. > > What gcc-config profiles get installed after this patch? We have only one now. But we can add a nossp but i would only use it for debuging and it don't mix well with distcc. The GCC_SPECS is not trasfered betvine the host and guest. /Magnus signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: [RFC] News item: GCC 4.8.3 defaults to -fstack-protector
tisdag 10 juni 2014 14.22.11 skrev Jeroen Roovers: > On Mon, 9 Jun 2014 21:46:56 -0600 > > Ryan Hill wrote: > > Yes. But now you've got me worried. We have to build gcc itself with > > -fno-stack-protector. Does compiling something with that flag give > > an error on hppa? Maybe give 4.8.2-r1 a whirl. > > Setting -fstack-protector on HPPA does this: > > warning: -fstack-protector not supported for this target [enabled by > default] > > Setting -fno-stack-protector on HPPA causes no problems and is > completely silent. > > > jer The arch that ssp will be enable by default is defined in the ebuild with SSP_STABLE or SSP_UCLIBC_STABLE. /Magnus
Re: [gentoo-dev] Re: [RFC] News item: GCC 4.8.3 defaults to -fstack-protector
torsdag 12 juni 2014 03.45.23 skrev Greg Turner: > On Wed, Jun 11, 2014 at 6:23 AM, Jeroen Roovers wrote: > > Will bug #332823 and its ilk somehow be mitigated? Emerging glibc with > > -fstack-protector still leads to similar problems. There doesn't > > currently seem to be a bug report about this that isn't marked INVALID. > > Is this a bug/limitation in glibc's actual code, or in glibc's build > environment? > > Asked another (wordier) way -- should I understand -- assuming nobody > adds some explicit -fno-stack-protector to the non-hardened profiles > or the glibc ebuild -- and, of course, also that the user has not put > it in make.conf or similar -- that this would break glibc compilation > in the base configurations of the x86/amd64 non-hardened profiles?* > > If that's so... that doesn't sound so great, does it? > > Just thinking out loud, I guess, but, the fact -- if it is, indeed, > still a fact (?) -- that, as of gcc-4.8.2, putting -fstack-protector > in your CFLAGS breaks glibc.ebuild doesn't /necessarily/ mean that, as > of gcc-4.8.3, leaving -fno-stack-protector out of your cflags would > also break it, even if they are supposed to mean the same thing -- > that would depend on the specific etiology of the problem. > > Sorry, perhaps Google Search would answer my question as readily as > portage, in which case, by all means feel free to "lmgtfy" my ass. > But if nobody knows the answer for sure, presumably you have the means > to find out, Ryan? > > If for any reason you need a guinea-pig, I have a non-hardened > triple-multilib (but mostly ABI_X86="64 32") workstation, here, that > I'm not afraid to break. > > -gmt > > *Apologies for the horrific run-on sentence! Glibc don't compile well with -fstack-protector* and that way we pass -fno-stack-protector to the compiler when we build the lib. It is done in common.eblit where we check if the compiler have the ssp spec added as hardened and the default gcc 4.9 and 4.8.3 have. The problem was when user did add -fstack-protector* to the cflag for the check didd't check that and upstream will just invalid the bug if you try to compile it with -fstack-protector*. /Magnus
Re: [gentoo-dev] Is Gentoo a Phoenix?
lördag 03 april 2010 12.19.19 skrev Tobias Scherbaum: > > > - hardened-sources are nowadays only available in an experimental > > > overlay, lots of users keep asking what's happening to the > > > hardened-sources on both the -dev but also the -hardened mailinglist. > > > Yeah, we do have people working on hardened stuff, but if people just > > > take what's happening in the portage tree they might think that the > > > hardened stuff they're relying on for their business isn't supported > > > any longer. > > > > With Zorry we just got a new recruit for working on hardened things, > > especially toolchain. It's not as dead as you make it sound ... > > Good to see there's something happening in hardened - but still, the > user outside of Gentoo still only is seeing: "Oh, no hardened-sources > update for nearly a year." > How long did it take for Hardened GCC to move to 4.X? And we are still lacking SSP support in the tree. We have lost almost all dev's in the herd the past years. As for hardened-sources we are working on it but that work has not hit the tree yet and that not a good situation. It will hit the tree soner or later. We work on our free time to and we don't have all the free time in the world to work on it. There is a long todo list. It is very time comsuming work on the toolchain, kernel, docs, bugs, recruit and help users at the same time. As tree dev that do all the work but we have users and some devs that help out too and that we are thankful for ther help. Hopefully we have something on the hardened-sources after next meeting. @ Paweł Hajdan, Jr. you could ask in hardened-ker...@gentoo.org what thay need for help or join #gentoo-hardened @ freenode.net And the hardened-sources in the hardened-development overlay have some regreesions that we are working on to fix. Sorry if i bing roude. Hardened at gentoo.org Magnus Granberg (Zorry)
Re: [gentoo-dev] suspicious code snipped in gcc-4.5* ebuilds
On Tuesday 05 October 2010 18.52.29 Petteri Räty wrote: > On 10/05/2010 02:32 PM, "Paweł Hajdan, Jr." wrote: > > I was just looking at some random ebuilds recently, and noticed this > > snippet in gcc-4.5* ebuilds: > > > > SSP_STABLE="amd64 x86 ppc ppc64 arm > > # uclibc need tls and nptl support for SSP support" > > SSP_UCLIBC_STABLE="" > > > > Please note how the #-starting comment is inside the SSP_STABLE variable > > declaration. It looks very obvious when seen in a syntax-coloring editor. > > > > I'm not sure if it breaks, as "uclibc", "need", "tls" etc. are not valid > > arch names, but it's still probably not intended. > > Open a bug? > > Regards, > Petteri allready fixed in cvs and it was not intended. /Magnus
[gentoo-dev] News item for hardened profile about gcc.
Hi Was thinking to post a news item for the hardened profile about the new GCC 4.4.4-r2 that have been stabled on x86 and amd64. Hardened at gentoo.org /Magnus (Zorry) Title: Info on GCC 4.4.4-r2 and GCC 3.X on Hardened profiles Author: Magnus Granberg Content-Type: text/plain Posted: 2010-10-27 Revision: 1 News-Item-Format: 1.0 Display-If-Profile: hardened/linux You may have noticed that GCC 4.4.4-r2 has gone stable on x86 and amd64. The other archs will follow later. We have enable SSP support by default on this and on newer versions for arches where it is supported, namely on x86, amd64, ppc, ppc64 and arm. The previous version GCC 4.3.4 had SSP, but it was not enabled by default. Older gcc's like 3.X versions will be obsoleted and we will not fix any bugs that work on GCC-4.4.4-r2 or newer, but fail with gcc 3.X.
Re: [gentoo-dev] Re: News item for hardened profile about gcc.
On Sunday 24 October 2010 02.44.00 Diego Elio Pettenò wrote: > Il giorno dom, 24/10/2010 alle 02.28 +0200, Magnus Granberg ha scritto: > > You may have noticed that GCC 4.4.4-r2 has gone stable on x86 and > > amd64. The other archs will follow later. We have enable SSP support > > by default on this and on newer versions for arches where it is > > supported, namely on x86, amd64, ppc, ppc64 and arm. The previous > > version GCC 4.3.4 had SSP, but it was not enabled by default. > > Older gcc's like 3.X versions will be obsoleted and we will not fix > > any bugs that work on GCC-4.4.4-r2 or newer, but fail with gcc 3.X. > > I'd suggest updating it to > > Display-If-Installed: > GCC 4.4.4-r2 is now stable (on x86 and amd64 as of 2010-10-24, other > architectures will follow later). Starting from this version, SSP > support is enabled by default for the architectures it is supported on > (namely x86, amd64, ppc, ppc64 and arm). Previously, GCC 4.3.4 had SSP > support but it was not enabled by default. > > Older GCC versions, such as the GCC 3.x series will be obsoleted; > problems arising on those versions, but not applying to GCC 4.4.4-r2 > will not be fixed, so please update to the new version. Thanks for the notes Have updated the news item with that changes. /Magnus (Zorry) Title: Info on GCC 4.4.4-r2 and GCC 3.X on Hardened profiles Author: Magnus Granberg Content-Type: text/plain Posted: 2010-10-27 Revision: 1.1 News-Item-Format: 1.0 Display-If-Install: signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: News item for hardened profile about gcc.
On Sunday 24 October 2010 10.04.34 Kfir Lavi wrote: > On Sun, Oct 24, 2010 at 3:34 AM, Duncan <1i5t5.dun...@cox.net> wrote: > > Magnus Granberg posted on Sun, 24 Oct 2010 03:01:40 +0200 as excerpted: > > > Display-If-Install: > > > Typo: > > > > Display-If-Installed: > > ^^ > > > > Meanwhile, the title reflects hardened profiles, but the updated > > conditions aren't viewed only on hardened. The no-support-for- > policy would seem reasonable for most profiles (don't know about the > > exotic archs). Either the title should be updated to reflect that it > > applies in general (not just on hardened), or the condition to display > > only on hardened should be maintained. Either way, making it clearer in > > the body as well would be wise, so people seeing it only on hardened (if > > it applies only to them, for example) will have less chance of missing > > that, if they have regular installs as well. > > > > But I don't remember whether multiple conditions are ANDed or ORed; they > > should be ANDed here, if it's to apply to ONLY hardened with > installed. > > > > -- > > Duncan - List replies preferred. No HTML msgs. > > "Every nonfree program has a lord, a master -- > > and if you use the program, he is your master." Richard Stallman > > Hi all, > After reading this post I went to wikipedia to read about the SSP. > http://en.wikipedia.org/wiki/Buffer_overflow_protection > At the paragraph "GCC Stack-Smashing Protector (ProPolice)", its written" > > "It was implemented as a patch to GCC 3.x; a less intrusive > reimplementation is included in the GCC 4.1 release. Currently, SSP is > standard in OpenBSD, FreeBSD (since 8.0), Ubuntu (since 8.04 LTS[3]), > and DragonFly BSD. It is also available in NetBSD (enabled by default > on x86), Debian and Gentoo, disabled by default." > > Now this should be changed, if the SSP flag is becoming default. > > Regards, > Kfir Updated the news item. Thanks for the notes Duncan. @Kfir It is only the hardened gcc that have the SSP enable as default. We can add that Gentoo (Hardened) have it enable. /Magnus /Magnus Title: Info about GCC on Hardened profiles Author: Magnus Granberg Content-Type: text/plain Posted: 2010-10-27 Revision: 3 News-Item-Format: 1.0 Display-If-Installed: signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: News item for hardened profile about gcc.
On Sunday 24 October 2010 12.04.13 Ulrich Mueller wrote: > >>>>> On Sun, 24 Oct 2010, Magnus Granberg wrote: > > Display-If-Installed: > If I understand portage's logic correctly, then this header will not > work. But you can use Display-If-Installed for the dependency atom and > Display-If-Profile for the profile. Headers of different type will be > linked by a logical and. > > > Revision: 3 > > This should still be 1. Revision should be increased only for changes > to an already committed news item, not during discussion. > > Ulrich Updated Thanks Ulrich for the notes. /Magnus Title: Info about GCC on Hardened profiles Author: Magnus Granberg Content-Type: text/plain Posted: 2010-10-27 Revision: 1 News-Item-Format: 1.0 Display-If-Installed: signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] News item for hardened profile about gcc.
On Sunday 24 October 2010 19.00.44 7v5w7go9ub0o wrote: > On 10/23/10 20:28, Magnus Granberg wrote: > > Hi > > > > Was thinking to post a news item for the hardened profile about the > > new GCC 4.4.4-r2 that have been stabled on x86 and amd64. > > Thank you for this milestone! > > "We have enable SSP support by default on this and on newer versions > for arches where it is supported..." > > As I read the above quote, 4.4.5 and 4.5.x also have SSP support enabled by > default; is this what was meant? > > Thanks Again Yes it what it says. /Magnus
Re: [gentoo-dev] Moving more hardening features to default?
torsdag 20 oktober 2011 13.17.33 skrev Mike Frysinger: > On Thursday 20 October 2011 12:47:27 Rich Freeman wrote: > > I was trying to draw a contrast between passive things like > > stack-protection and things that really get in your face like MAC. > > the trouble was in the context quoting then ... it sounded like you were > proposing PaX by default > > i am a fan of things that "just work" though which is why i was happy to > merge the fortify source code. most of that checking is done at compile > time, so the runtime overhead is generally small. and in terms of packages > that did break, it was (more often than not) because they were broken > already but we never noticed. > -mike Hi Debian has start to add some hardened features but take a look at ubuntu https://wiki.ubuntu.com/Security/Features Adding ssp support to main would not be a problem for most package works with it. We use same patch as ubuntu's toolchain to enable ssp, but we enable -fstack-protector-all instead of -fstack-protector. You will, however, have some performance penalty enabling it. Adding PIE to main is much harder than ssp. On x86 it will have a high performance penalty and a lot of trouble with asm code. The only arch I would add PIE on is amd64 where it will have only a minor performance penalty and we already have shared libs compile with PIC. The biggest problem we have with PIE on amd64 is asm code in the apps where upstream is not that interested in making the asm PIC aware. It hards to keep the patches up to date when they are not maintained upstream. There are about 30 packages which have problems with PIE. We either add patch to these or else use filter-flags on them. my 2c /Magnus (Zorry)
Re: [gentoo-dev] Re: Moving more hardening features to default?
fredag 21 oktober 2011 15.25.54 skrev Duncan: > Mike Frysinger posted on Fri, 21 Oct 2011 08:13:22 -0400 as excerpted: > > On Thursday 20 October 2011 23:20:35 Duncan wrote: > >> Magnus G suggests possibly adding PIE to amd64, which is already PIC, > > > > this isn't quite right. amd64 shared objects (i.e. libraries) are PIC. > > the applications are not. > > Thanks for the correction. I knew the library think but supposed that > was the difference between PIC/PIE, the E/executable for executables > only, the more generic C/code for the feature applied to shared objects. > > Seems there's a bit more to it than that. Thanks again, I can look it up > now that I know to do so. > > > usually these packages are multimedia related. like ffmpeg iirc. so i > > think the impact is much greater than your estimate here. > I don't have any probs with ffmpeg. We disable the asm stuff only for x86 and not amd64 and that is the case on alot of the multimedia related packages. Most problem we have now is the packages in app-emulation > I figured mm, but also assumed strip-flags-like exceptions (probably > controlled via USE flag) for packages where the default was really > costly. But now that I think of it, implementing that as arch defaults > while allowing overrides isn't quite the simple matter it is for user-set > CFLAGS, etc, and strip-flags, etc. We allready use pic USE flag, filter-flags -fPIE or gcc-specs-pie to disable or do stuff so the package works. > > I assume it can still be done, but am not in a position to estimate > whether it'd be worth the cost to implement. > > >> What about x32, tho? Does it get PIC by default too > > > > x32 is same as x86_64 wrt PIC > > Good to know. Thanks. /Magnus
[gentoo-dev] Cluster tinderbox poc
Hi As some of you may know, I have been working on code for a tinderbox with frontend support. I think its time to move it to a offcial project. The Proof-Of-Concept (poc) is almost ready, but it still have alot of the frontend left to do. You can see the logs and summit bugsreports and chose what to build. The poc is runing on a 64core box with help of ganeti to manges the virtual machines (vm). I have 4 vm's runing for now but I will add 4 more later. I'm building the vm's with help of ganeti-instance-gentoobootstrap. The vm's query the db for what to build. Db is update with tree info and list to builds for the vm's. The vm's are runing python code that call portage api to build the packages in the list. The frontend is just django. Featuers -Support multiplay repos -Support any arch there the python code can run. -Attach the build logs. -Use the db to store the repex for log search. /Magnus G.
