On Sun, 2017-07-02 at 08:32 +1000, Allan McRae wrote: > On 02/07/17 06:51, Bartłomiej Piotrowski wrote: > > On 2017-06-30 23:44, Allan McRae wrote: > > > On 30/06/17 19:07, Bartłomiej Piotrowski wrote: > > > > On 2016-10-24 05:56, Allan McRae wrote: > > > > > 1) building gcc to enable PIE by default > > > > > > > > I am in the middle of rebuilding gcc with --enable-default-pie. > > > > When it > > > > finishes, I will start a todo for rebuilding packages with > > > > static libraries. > > > > > > > > I also enabled --enable-default-ssp, which means that > > > > -fstack-protector-strong will be dropped from our CFLAGS (as it > > > > will be > > > > enforced by gcc) on the next opportunity. > > > > > > > > > > Are you adding full RELRO + no-plt at the same time? > > > > > > A > > > > > > > Yes, and -fstack-check=specific too, although I might drop no-plt if > > it > > will cause too many builders. > > > > I thought the conclusion from the Stack Clash bugs was that the > current > -fstack-check was fundamentally flawed and was being completely > rewritten for the next gcc. Is the "=specific" version OK?
It's safe and they fixed the performance issue already, but it's not perfect in terms of exploit mitigation. They didn't mention that in their report but there are issues involving sizes larger than PTRDIFF_MAX / SSIZE_MAX so for an unbounded VLA / alloca it doesn't necessarily mitigate exploitation. The generic -fstack-check implementation is broken / probably still unsafe, but that's not what's used on x86. The -fstack-check=specific switch just makes sure that the generic impl isn't being used which is already the case on x86. The other issue brought up by Red Hat is that -fstack-check assumes all code is compiled with -fstack-check and optimizes out checks that aren't strictly required if other code is compiled with it. I don't see that as the big issue that they do. Compiling all code with it isn't very far fetched and by delaying it for that reason, they're making it into a bigger issue than starting ASAP. It also sometimes leaves unchecked gaps of a few pages. The larger gap in new kernels deals with that for the main thread, for not secondary threads... glibc will need to adopt a larger, and they seem to be waiting for the kernel to expose the gap size via a sysctl rather than switching to the new way as the default before then. Technically those can be caught for VLAs (but not alloca?) via -fsanitize=vla-bound, but GCC is missing -fsanitize-trap=vla-bound, it only has -fsanitize-undefined-trap-on-error to convert all of the UBSan sanitizers into production trapping mode which might not be desired.
