Re: Porter roll call for Debian Stretch
On 09/21/2016 08:41 AM, Riku Voipio wrote: > AFAIK Address space randomizing is not really helpful on 32 bit > architectures - there is just not that many places to randomize to[1]. Well, sure, but there's still a huge difference in an explot with 100% reliability, or an exploit that will just crash the program in 95% of cases. Sure, if there's an easy way to repeatedly try the exploit 20 times, it won't be a show-stopper, but it will make the life of people who want to exploit a flaw just a tiny bit harder. > At least previously, PIE added ~10% to binary size, At least on x86 there have been substantial improvements in receent gcc versions when it comes to PIE support, so the impact of PIE on executables even on 32bit is a lot smaller than it used to be. I don't know about ARM though. Consider the following two data points: - A _lot_ of code in Debian is in shared libraries, which are compiled with -fPIC anyway. Many executables only spend a fraction of their instructions in the executable code itself. - It's been considered best practice to enable PIE executables if possible (via hardening=+all or similar), so many programs in Debian (and e.g. all of my packages except one) already use that. I suspect that a lot of of code that you are currently running is already PIE, especially in the packages that are more actively maintained. Regards, Christian
Re: [Stretch] Status for architecture qualification
On 06/05/2016 02:00 PM, Holger Levsen wrote: > On Sun, Jun 05, 2016 at 01:26:39PM +0200, John Paul Adrian Glaubitz wrote: >> ppc64: >> >> This architecture is basically on par with the release architectures. We >> have over >> 11.000 packages installed > [...] >> sparc64: >> We are close to 11.000 installed packages. > > I'm not sure whether you are talking about source or binary packages but > sid/amd64 has over 24000 source packages and over 5 binary packages, > so I would call the above "on par". Or what am I missing? But around 12000 of those source packages only build Arch: all packages. If you look at amd64's buildd stats in sid, there are ~12000 source packages in the Installed state: https://buildd.debian.org/status/architecture.php?a=amd64=sid i386 also has ~12000; arm64, armhf, armel, powerpc and ppc64 have ~11500 each; mipsel has ~11300 and mips has ~11000. Arch: all has ~15000 source packages in the Installed state (but that also counts packages that build both Arch: !all and Arch: all. From these statistics, sparc64 appears to be a tiny bit behind mips in terms of archive coverage, but not by much. Regards, Christian signature.asc Description: OpenPGP digital signature
Unofficial sparc64 porterboxes? (For problem unreproducible in Qemu)
Hi, I'd like to ask if I could get access to an unofficial sparc64 box? (There are no official porterboxes, as I've been told by DSA.) I'm currently investigating unit test failures of mksh when compiled with dietlibc on sparc64 (I co-maintain dietlibc, and mksh's test suite is very good at finding libc bugs), see [1] for a recent log. My problem is that under qemu-system-sparc64 [2] I simply cannot reproduce this problem, the test suite of mksh passes when compiled against dietlibc. (The other bugs that I could reproduce, see e.g. the problems in the sid version [3], I was able to fix in dietlibc in experimental.) Therefore it would be good if I could access to some real hardware to figure out this problem. Is there such a possibility? Thanks! Regards, Christian [1] https://buildd.debian.org/status/fetch.php?pkg=mksh=sparc64=52c-2exp3=1463270788 Look for: FAIL ../../check.t:regression-66 FAIL ../../check.t:pipeline-2 [2] https://wiki.debian.org/Sparc64Qemu [3] https://buildd.debian.org/status/fetch.php?pkg=mksh=sparc64=52c-2=1460498978 Look for: FAIL ../../debian/mtest.t:mtest-select-works signature.asc Description: OpenPGP digital signature
