[arch-dev-public] Changing compilation flags

[Daniel Micay]

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.