Hi! On Sun, 2014-09-07 at 20:31:58 +0200, Bálint Réczey wrote: > 2014-09-07 17:26 GMT+02:00 Guillem Jover <[email protected]>: > > On Sun, 2014-09-07 at 15:01:35 +0200, Balint Reczey wrote: > >> Package: dpkg > >> Version: 1.17.13 > >> Severity: wishlist > >> Tags: patch
> >> I'm working on a new port, hardened-amd64 [1]. > > > > This does not what dpkg ports are meant to denote, as I think was > > mentioned in that thread. If the ports are ABI compatible then they > > are the same port. The lpia port was such a thing, which I disagreed > > with at the time but accepted anyway, and that was a mistake I'm not > > going to repeat. I'm planning on removing lpia support soonish to > > avoid anyone else take that as a precedent to follow. > > > > This is the equivalent of bumping the instruction set baseline or > > enabling a different set of build flags by default, etc. Please see > > the recent Boostrap Sprint notes on the multiple ISAs section, which > > is relevant for your scenario. > > > > In any case I'm not planning on adding support for a hardened-amd64 > > architecture, sorry. > Sorry for not mentioning it earlier, but I don't intend to keep ABI > compatibility. In what ways? You mention some above, but I'd like to understand to what extend. > Libraries compiled with ASAN can't be loaded binaries without ASAN > support, thus the ABI can be considered to be different. Do you have more information on this, I didn't see anything obvious by reading the (almost non-existent) information in gcc, and the canonical one in <http://dev.chromium.org/developers/testing/addresssanitizer>. > I also plan removing some functions which are deprecated for security > reasons but path of the ABI such as getwd(), thus ABI compatibility is > broken again, in a different way. Well, these kind of functions can be deactivated w/o breaking ABI. For example getwd() could return NULL and set errno to ENAMETOOLONG. Or even abort at run-time. Or it could be marked to emit an error at build-time. > Third, I would like to enable breaking the ABI for enabling efficient > tracking of pointers through library calls. SoftBound + CETS [2] > projects are researching this way and if they come up with something > usable I would like to adopt it. 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. > >> The attached patches adds > >> the new port and enables ASAN and UBSAN through the hardening flags. > >> The flags are disabled on other architectures by default even when using > >> hardening=all, since ASAN causes significant slowdown and UBSAN will > >> probably reveal a lot of issues in many packages. > > > > I'd be fine with adding ASAN and UBSAN or any other hardening stuff, > > disabled by default on a feature area, but if they do not make sense > > to be enabled by “all” then they do not belong in the hardening feature > > area, probably in another one. OOC how many packages do enable all > > hardening features? > I think distinguishing between 'all' and 'extra' has its history, gcc > -Wall and -Wextra are similar to our case. I think ASAN should not be > part of 'all' because it should be enebled for packages shipping > binaries first, then in packages shipping the libraries used by the > binaries, thus it is not a per-package decision to enable ASAN. > UBSAN is different, I think it could be added to 'all', but I'm not > sure how many packages use 'all' and I did not want to break them. > Maybe after a full archive rebuild revealing the breakages. 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? > >> Please consired accepting the patches despite the fact that > >> hardened-amd64 is not an official port yet. It would help the > >> bootstrapping efforts and patch 2 would make it easier to experiment > >> with ASAN and UBSAN for others. > > > > It's not a matter of it being or not an official port, the main > > requirement is that the GNU triplet is officially recognized and that > > the naming and the thing makes sense. Which does not in this case. > I'm not sure which part of the proposal you are questioning here so I > try to answer all of them. 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. > I think there was precedent for adopting an GNU triplet first in > Debian then later getting it adopted upstream. That might have been the case in the distant past, I'd rather have it the other way around, in general. > 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 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. Thanks, Guillem -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
