Bug#1022766: dpkg-shlibdeps: repeatedly emits duplicate warnings
Package: dpkg-dev Version: 1.21.9 Severity: normal While checking the nvida-cuda-toolkit buildd logs [1], I came across a long sequence of repeated error messages: pkg-shlibdeps: warning: can't extract name and version from library name 'libfoobar.so' There are about 40 repetitions of this warning (with no further messages interleaved) for most of the libraries, but I don't know what this number corresponds to. Since nvida-cuda-toolkit just repacks upstream binary libraries we unfortunately have to cope with a lot of libraries without proper sonames. Andreas [1] https://buildd.debian.org/status/package.php?p=nvidia-cuda-toolkit
Bug#1021292: Enabling branch protection on amd64 and arm64
I have been in discussion with Guillem about enabling the various branch protection mechanisms available on newer x86 and arm CPUs. These are hardware features (new instructions) that 'tag' pointers and branch targets to make it much harder for malicious code to implement ROP (return oriented programming) and JOP (Jump oriented programming) attacks. They have been implemented on both architectures in such a way that they can be generally enabled and are simply ignored on hardware that doesn't support them (the new instructions are in the NOP space). These features have been enabled in other distros for some time and we've done an archive rebuild of arm64 to check that there was not significant breakage. There is a lot of discussion of the details of this and the pros/cons of enabling this by default in the thread so I will try to keep this mail as a summary and suggest you go read https://lists.debian.org/debian-dpkg/2022/05/msg00022.html and https://lists.debian.org/debian-dpkg/2022/06/msg0.html if you want to know how it works, and all the details. We decided that the best thing to do was create a new hardening flags feature called 'branch' to add to the existing set. This enables -mbranch-protection=standard on arm64, and -fcf-protection on amd64 (yes it would have been nice if the gcc people had used common flags across the arches, but there you go) If/when other arches get similar functionality those would be enabled under this heading too (Are there any already that I don;t know about?) There is a dpkg branch containing this feature here: https://git.hadrons.org/git/debian/dpkg/dpkg.git/log/?h=next/dpkg-buildflags-feature-branch And a bug to track progress here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1021292 So the immediate issue now is whether or not to enable this by default in bookworm? It's a significant protection on newish hardware, which those who've worked on it (and I now, having investigated) believe should be on by default. We have a general policy of enabling reaosnably low-cost security features by default, and this is one of those. It's a fairly low-risk thing to do, especially as others have gone before us (Rhel made -fcf-protection the gcc default in 2018, and Suse in Oct 2021. Suse turned on branch-protection=standard (ie BTI+PAC) on arm64 in nov 2020), but it is changing the defaults. Like all dpkg-buildflags it can easily be disabled for a particular package and there is a kernel option to turn it off on a particular machine if issues are encountered (and no doubt we will find a couple). I hope that all makes sense. Wookey -- Principal hats: Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Bug#1021292: Enabling branch protection on amd64 and arm64
On Tue, 25 Oct 2022 at 15:34:26 +0100, Wookey wrote: > These are hardware features (new instructions) that 'tag' pointers and > branch targets to make it much harder for malicious code to implement > ROP (return oriented programming) and JOP (Jump oriented programming) > attacks. > > They have been implemented on both architectures in such a way that > they can be generally enabled and are simply ignored on hardware that > doesn't support them (the new instructions are in the NOP space). Does this have the same restrictions as CET, which gcc briefly enabled on x86 by default, but had to roll back[1] and later enable on a smaller subset of architectures[2], because the new instructions are only NOPs on x86_64 and modern i386, and are non-baseline (illegal instruction) on older or more-embedded i386 like the ones in our current i386 baseline? If yes, we'll have to be careful to only enable this on architectures where our baseline allows it. IIRC, Geode and VIA CPUs are the ones that usually cause trouble for i386. Of course, raising the i386 baseline would mitigate or solve that, at the cost of dropping support for some CPUs. [1] https://tracker.debian.org/news/1254900/accepted-gcc-11-1120-4-source-into-unstable/ [2] https://tracker.debian.org/news/1256872/accepted-gcc-11-1120-5-source-into-unstable/ smcv
Bug#1021292: Enabling branch protection on amd64 and arm64
On 2022-10-25 16:10 +0100, Simon McVittie wrote:
> On Tue, 25 Oct 2022 at 15:34:26 +0100, Wookey wrote:
> > These are hardware features (new instructions) that 'tag' pointers and
> > branch targets to make it much harder for malicious code to implement
> > ROP (return oriented programming) and JOP (Jump oriented programming)
> > attacks.
> >
> > They have been implemented on both architectures in such a way that
> > they can be generally enabled and are simply ignored on hardware that
> > doesn't support them (the new instructions are in the NOP space).
>
> Does this have the same restrictions as CET, which gcc briefly enabled
> on x86 by default, but had to roll back[1] and later enable on a smaller
> subset of architectures[2], because the new instructions are only NOPs
> on x86_64 and modern i386, and are non-baseline (illegal instruction)
> on older or more-embedded i386 like the ones in our current i386 baseline?
I'm not sure (I know a lot more about the arm64 side of this than the
amd64 side), but we are only enabling this on amd64, not i386. amd64
binaries don't run on i386 so I don't think any practical issue
actually arises. You have reminded me that I guess it should be turned
on for x32 too.
> If yes, we'll have to be careful to only enable this on architectures
> where our baseline allows it. IIRC, Geode and VIA CPUs are the ones that
> usually cause trouble for i386.
Right, and that's the plan.
The patch looks approx like this:
+# Branch protection
+if ($use_feature{hardening}{branch}) {
+my $flag;
+if ($cpu eq 'arm64') {
+$flag = '-mbranch-protection=standard';
+} elsif ($cpu eq 'amd64') {
+$flag = '-fcf-protection';
+}
+$flags->append($_, $flag) foreach @compile_flags;
+}
Wookey
--
Principal hats: Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: PGP signature
Bug#1022766: dpkg-shlibdeps: repeatedly emits duplicate warnings
Hi!
On Tue, 2022-10-25 at 14:23:18 +0200, Andreas Beckmann wrote:
> Package: dpkg-dev
> Version: 1.21.9
> Severity: normal
> While checking the nvida-cuda-toolkit buildd logs [1], I came across a
> long sequence of repeated error messages:
>
> pkg-shlibdeps: warning: can't extract name and version from library name
> 'libfoobar.so'
>
> There are about 40 repetitions of this warning (with no further messages
> interleaved) for most of the libraries, but I don't know what this
> number corresponds to.
> Since nvida-cuda-toolkit just repacks upstream binary libraries we
> unfortunately have to cope with a lot of libraries without proper sonames.
> [1] https://buildd.debian.org/status/package.php?p=nvidia-cuda-toolkit
Ah, I guess something like the attached patch might do? In addition to
somewhat improving performance. :)
Thanks,
Guillem
From 12e690ec338d7ba2e808ae7f6ba7c31e060b0e8e Mon Sep 17 00:00:00 2001
From: Guillem Jover
Date: Tue, 25 Oct 2022 18:36:16 +0200
Subject: [PATCH] dpkg-shlibdeps: Cache soname check against shlibs files
Closes: #1022766
---
scripts/dpkg-shlibdeps.pl | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/scripts/dpkg-shlibdeps.pl b/scripts/dpkg-shlibdeps.pl
index 6c8a2d3ab..47e79ca13 100755
--- a/scripts/dpkg-shlibdeps.pl
+++ b/scripts/dpkg-shlibdeps.pl
@@ -172,7 +172,8 @@ my %global_soname_notfound;
my %global_soname_used;
my %global_soname_needed;
-# Symfile and objdump caches
+# Shlibs, Symfile and objdump caches
+my %shlibs_cache;
my %symfile_cache;
my %objdump_cache;
my %symfile_has_soname_cache;
@@ -721,6 +722,10 @@ sub split_soname {
sub extract_from_shlibs {
my ($soname, $shlibfile) = @_;
+if (exists $shlibs_cache{$shlibfile}{$soname}) {
+return $shlibs_cache{$shlibfile}{$soname};
+}
+
my $shlibs_re = qr{
^\s*
(?:(\S+):\s+)? # Optional type
@@ -738,6 +743,7 @@ sub extract_from_shlibs {
unless (defined $libname) {
warning(g_("can't extract name and version from library name '%s'"),
$soname);
+$shlibs_cache{$shlibfile}{$soname} = undef;
return;
}
# Open shlibs file
@@ -769,6 +775,7 @@ sub extract_from_shlibs {
}
}
close($shlibs_fh);
+$shlibs_cache{$shlibfile}{$soname} = $dep;
return $dep;
}
--
2.37.2
