Hi Gulliem,
2014-09-07 17:26 GMT+02:00 Guillem Jover <guil...@debian.org>:
> Hi!
>
> 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.
Libraries compiled with ASAN can't be loaded binaries without ASAN
support, thus the ABI can be considered to be different.
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.
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.
Based on the three reasons above please don't consider amd64 and
hardened-amd64 ABI compatible and please don't reject it due to having
compatible ABI.
>
>> 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.
>
>> Dpkg for example builds fine with ASAN (with fixed #760690), but UBSAN
>> makes it FTBFS due to the following issue:
>> .../dpkg.git$ DEB_BUILD_MAINT_OPTIONS=hardening=all,+asan,+ubsan
>> dpkg-buildpackage
>> ...
>>
>> PATH="../src:../scripts:../utils:/usr/lib/ccache:/home/rbalint/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games"
>> \
>> LC_ALL=C \
>> \
>> srcdir=../../src builddir=. \
>> PERL_DL_NONLAZY=1 \
>> PERL5OPT= \
>> /usr/bin/perl -MTAP::Harness -e ' my $harness = TAP::Harness->new({
>> lib => [ "../../scripts" ], color => 1, verbosity => 0, failures => 1,
>> }); my $aggregate = $harness->runtests(@ARGV); die "FAIL: test suite has
>> errors\n" if $aggregate->has_errors;' \
>> ../../src/t/dpkg_divert.t
>> ../../src/t/dpkg_divert.t .. 1/257
>> not ok 62 - --list stderr
>>
>> # Failed test '--list stderr'
>> # at ../../src/t/dpkg_divert.t line 106.
>> # got: '../../src/filesdb.c:581:21: runtime error: signed
>> integer overflow: 313137907 * 1787 cannot be represented in type 'int'
>> # '
>> # expected: ''
>> not ok 65 - --list * stderr
>>
>> The third patch fixes the issue.
>
> Thanks! I've merged this one locally, will be included in 1.17.14.
>
>> 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 think there was precedent for adopting an GNU triplet first in
Debian then later getting it adopted upstream.
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.
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.
IMO the multiple ISAs proposal which would work for mips does not work
here due to binaries and libraries are not being interchangeable
separately.
I think if this port gets accepted it will be the third most popular
port after it stabilizes and it will also let us discover and fix a
lot of bugs early in the archive.
Cheers,
Balint
[2] https://www.cs.rutgers.edu/~santosh.nagarakatte/softbound/
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
