Hi! On Fri, 2016-01-29 at 12:14:30 +0100, Bálint Réczey wrote: > 2016-01-29 0:42 GMT+01:00 Guillem Jover <guil...@debian.org>: > > On Tue, 2016-01-26 at 15:23:43 +0100, Balint Reczey wrote: > > > For hardened1-* the major difference from the amd64 ABI is enabling ASAN > > > and I will stick to that. > > > I also #define __GNU_FEATURESET_HARDENED1__ in libc to let config.guess > > > detect the gnuhardened1 variant, but this does not need changes in dpkg > > > and will be upstreamed to GNU config project. > > > > I'd probably just define something that makes it clear that glibc is > > being built with ASAN which implies that everything else needs to as > > well. Perhaps something like __GNU_ASAN_ABI or __GLIBC_USING_ASAN or > > something similar, although it would be nice to get glibc upstream > > to decide or agree with such a macro so that it can be used by others?
> Originally I had this idea, too, but UBSAN is also enabled which may deserve > its own flag. Since the ABI is defined by a set of features it seemed to be > an even better solution to come up with a macro unique to this ABI. > This makes the detection of the ABI much simpler in config.guess. > I indeed will discuss that with upstream and settle on a solution satisfying > all > parties. I the meantime using this unique macro seems to be one good solution. Are UBSAN and TSAN really ABI changing features? But in any case yeah, please get this upstreamed first. > >> Many of the patches I'm filing enable sanitized rebuild of the amd64 > >> archive, but I think a separate port would be an ideal solution both for > >> the Debian project and for our users. > > > > Perhaps, I'm still unsure about the actual demand of such thing, time > > will tell, and OTOH we support ports with very low popcon numbers so… > I would like to assess the demand in the coming weeks. If there is only very > few > people interested I won't push it as an official port. I respect your > and other's > time more than pushing something that would not be used. Well most of the time is in getting the details right, once that's done there's not much to do from my side. :) And I'm afraid we are already spending time getting the details right, which can only be a good thing anyway. :) In any case, thanks for canvassing if the port has support. > >> >From 452b9127410427837428e75062cc9fa17633d974 Mon Sep 17 00:00:00 2001 > >> From: Balint Reczey <bal...@balintreczey.hu> > >> Date: Sun, 20 Sep 2015 19:24:23 +0200 > >> Subject: [PATCH 1/2] Add hardened1-linux-<cpu> ports support > >> > >> Those ports ar based on simple <cpu> ports with a set of defaults > >> changed to provide better security. > >> diff --git a/ostable b/ostable > >> index 10e0d3a..678196a 100644 > >> --- a/ostable > >> +++ b/ostable > >> @@ -23,6 +23,7 @@ gnuabi64-linux linux-gnuabi64 > >> linux[^-]*-gnuabi64 > >> gnuspe-linux linux-gnuspe linux[^-]*-gnuspe > >> gnux32-linux linux-gnux32 linux[^-]*-gnux32 > >> gnu-linux linux-gnu linux[^-]*(-gnu.*)? > >> +gnuhardened1-linux linux-gnuhardened1 linux[^-]*(-gnuhardened1.*)? > > > > Given that the thing defining the ABI difference here is the enabled > > ASAN I think it would make more sense and be more clear to name the > > GNU triplet something like «<cpu>-linux-gnuasan». BTW why hardened_1_, > > is this to prepare for a possible ABI break? That to me seems a bit > > concerning? > After if evolved like gnuasan -> gnuausan ->gnutausan->... in my private repo > I just tried to pick something simple, unique enough and considered ASN.1 as > an example of finding future-proof names. :-) > I chose gnuhardened1 as the unique string to allow a gnuhardened2 port in case > there is a very different, incompatible set of hardening features found and we > also want to keep the old set as a port. I have no plans for hardened2 BTW, It's a bit concerning that many of these features are ABI breaking (if that is really the case for UBSAN and TSAN too, as I asked above, for ASAN last time I looked around it was not very clear from the sparse documentation I could find), because it means if some other new feature appears that also breaks the ABI, we can either not use it or have to create a new port, which seems very suboptimal. > linux[^-]*(-gnuhardened.*)? without the _1_ would match ...hardened2, too, > which would complicate things, too. We can always just use an exact match, though. The 1 there just looks very arbitrary and ugly to me. At least something like the MIPS R6 ports have a defined meaning. Thanks, Guillem
