Control: tags -1 moreinfo Hi!
On Thu, 2019-01-10 at 16:20:23 +0100, Florian Weimer wrote: > * Harlan Lieberman-Berg: > > It would be Really Awesome (TM) if we could add the > > -fstack-clash-protection flag to our default hardening posture. This > > would have provided protection against the recent System Down > > vulnerability (CVE-2018-16864, CVE-2018-16865, CVE-2018-16866, aka > > #918841 and #918848). The process to consdier new build flags for the default is: <https://wiki.debian.org/Teams/Dpkg/FAQ#Q:_Can_we_add_support_for_new_default_build_flags_to_dpkg-buildflags.3F> > Note that -fstack-clash-protection is only fully functional on some > architectures. I know that the following GCC architectures work with > GCC 8: > > i386 > powerpc64 (big endian and little endian) > s390x > x86-64 Hmm, that's unfortunate, but could be handled, in the same ways other flags are. > There is a patch to fix it for aarch64 as well, but I think it > requires 64K page sizes. I think the powerpc64 probing uses 4K > offsets, but someone should verify that (the GCC builds I have readily > access to are only expected to be used with 64K pages on POWER). Ok. > The challenge here is that the generic version of > -fstack-clash-protection has bugs that are similar to of > -fstack-check. But with proper architecture support, the probes will > never hit memory outside the required stack space (which is a frequent > problem with -fstack-check). Some care is also necessary to generate > correct asynchronous unwinding information for the probes, and > valgrind may need some adjustment as well. So, from this, it seems that this needs more testing, and possibly support elsewhere. On Thu, 2019-01-10 at 09:42:10 -0500, Harlan Lieberman-Berg wrote: > I'd realllllllly love it if it would make it into buster, but I know > that's an awfully aggressive timeline considering the upcoming freeze. > Still, there are an awfully high number of vulnerabilities that are > lurking that this might be able to help patch up. Yeah, that seems too tight, but feel free to start checking stuff, and gathering further information. Once that's done a thread on debian-devel would be appreciated. > Happy to discuss more, and if we need to do a test archive-rebuild > with that change made, I can probably do that in the upcoming weekend. Given its arch-dependent behavior this might need more exposure than a simple rebuild on say amd64. Enabling this at the beginning of a release cycle might seem more appropriate. I guess we could always add the support but disabled by default. That would make playing with this slightly more convenient. Thanks, Guillem
