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? > > 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… > >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? > 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. :) Thanks, Guillem
