Hi Guillem, 2016-01-29 0:42 GMT+01:00 Guillem Jover <guil...@debian.org>: > Hi! > > On Tue, 2016-01-26 at 15:23:43 +0100, Balint Reczey wrote: >> Package: dpkg >> Version: 1.18.4 >> Severity: wishlist >> Tags: patch >> User: bal...@balintreczey.hu >> Usertags: hardened1-linux-amd64 > >> 2014-09-15 16:44 GMT+02:00 Guillem Jover <guil...@debian.org>: >> > Well, once the architecture is accepted it's “supposed” to have a >> > stable os-kernel-cpu ABI defined, it seems to me you want to have the >> > freedom to experiment with new developments that might break ABI? In >> > which case I think this really should be a private playground until >> > something stable has been defined. > >> 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.
> >> > What I meant is that I'm going to add a new feature area named “qa”, >> > alongside “hardening”, so it seems it might make sense to have a new >> > “sanitizer” (or similar name) feature area, with all new interesting >> > sanitizer options, such as asan, ubsan, tsan, lsan, etc. Does that >> > make more sense now? > >> Thank you for adding the feature area, I built my new patches on top of >> that. > > See my next reply, but I don't think this is a good idea. > >> > I added a FAQ entry about all the requirements (I could remember) a >> > new port needs to fulfill at the end of >> > <https://wiki.debian.org/Teams/Dpkg/FAQ>. As it stands this >> > architecture seems to fail several of them. > >> Thank you for the FAQ, it helped a lot. I now renamed the port to >> follow uclibc's example. >> Do you think the hardened1-linux-amd64 name would be OK? I'm working on >> fulfilling all requirements. > > It's better indeed, but I have some concerns, see below. > >> >> I'm not tied to a name. I think it is reasonable and reflects that >> >> this is not a port with a different kernel (hardened-amd64 vs. >> >> kfreebsd-i386), but I'm open for better proposals. >> > >> > Any Linux port needs to use a single word name. > >> I think the triple-word name also conforms to current practices, >> but I see that hardened-amd64 was a no-go. > > Using a triplet would be fine here yes, but we might actually want to > consider fixing the libc/abi entanglement first? :/ CCing josch and > Helmut. > > <https://wiki.debian.org/Teams/Dpkg/TimeTravelFixes> > >> >> I tried to explain the goals of having this new port (improved >> >> security, discovering more bugs using the Debian buildds >> >> automatically) and I think they make sense. >> > >> > Oh! I think those goals do make sense, I'm not sure if they make sense >> > as part of an entire new port. > >> 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. > >> >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. >> --- >> ostable | 1 + >> triplettable | 1 + >> 2 files changed, 2 insertions(+) >> >> 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, linux[^-]*(-gnuhardened.*)? without the _1_ would match ...hardened2, too, which would complicate things, too. > >> gnueabihf-kfreebsd kfreebsd-gnueabihf kfreebsd[^-]*-gnueabihf >> gnu-kfreebsd kfreebsd-gnu kfreebsd[^-]*(-gnu.*)? >> gnu-knetbsd knetbsd-gnu knetbsd[^-]*(-gnu.*)? >> diff --git a/triplettable b/triplettable >> index 568a6b9..a2bd1e5 100644 >> --- a/triplettable >> +++ b/triplettable >> @@ -16,6 +16,7 @@ gnuabi64-linux-mips64 mips64 >> gnuspe-linux-powerpc powerpcspe >> gnux32-linux-amd64 x32 >> gnu-linux-<cpu> <cpu> >> +gnuhardened1-linux-<cpu> hardened1-linux-<cpu> >> gnueabihf-kfreebsd-arm kfreebsd-armhf >> gnu-kfreebsd-<cpu> kfreebsd-<cpu> >> gnu-knetbsd-<cpu> knetbsd-<cpu> > > Of course then having the dpkg architecture name be gnuasan-linux-amd64 > (or asan-gnu-linux-amd64 with the debquadruplet) might not be as > flashy! But I think it's more accurate. :) It would be more descriptive, but with UBSAN enabled it would also be a bit more misleading. I have just fixed apt to handle debtriplets, I'm nut sure if we want to fix everything to allow debquadruplets right now. :-) And hey, flashy name is a real value, I heard that in a marketing course. :-) Cheers, Balint
