gcc: DEP and ASLR not enabled by default

[salowenh]

The libgsf is flagged by tools such as BinSkim due to apparently not enabled safe exception handlers, DEP and ASLR security options. Any thoughts on how to create a more secure compilation?

[salowenh]

@jeremyd2019 can you please share how I can use your changes to build? I've pulled the latest master yet I don't see a new msys build

[revelator]

Only a new patch was added im not sure a rebuild has taken place yet as you need all dependant libraries to also be linked with aslr support. For binutils we need iconv and zlib rebuilt with aslr and gcc need's gmp isl mpfr mpc iconv and gettext i think. Im doing a rebuild atm of those to see if things break and in that case on what. So it will probably take some time before any packages with this enabled are avaliable since we are testing stuff atm.

[salowenh]

@revelator thanks for the quick reply. I'm ok with building the packages myself but it sounds like waiting will be smarter as issues may rise. Just for general understanding, any idea how long these issues usual takes? days/weeks/months/era 😉 ?

[revelator]

probably not that long ;) i just finished rebuilding my compiler and dependencies and no problems so far. But there are a lot of other packages to check so something might turn up.

Next goal will be bootstrapping gcc with aslr and dep enabled with my newly built compiler and dependencies and then see where it takes me.

Then if nothing breaks i will try to build gobject introspection with aslr and dep as that one has allways had problems with it enabled before.

[revelator]

Well gcc itself does not like being built with aslr ...

    build/genmddeps.o build/read-md.o build/errors.o ../build-x86_64-w64-mingw32/libiberty/libiberty.a
build/genmddeps.exe ../../gcc-9.3.0/gcc/common.md ../../gcc-9.3.0/gcc/config/i386/i386.md > tmp-mddeps
/bin/sh: linje 1: 30585 Segmentation fault      build/genmddeps.exe ../../gcc-9.3.0/gcc/common.md ../../gcc-9.3.0/gcc/config/i386/i386.md > tmp-mddeps```

the flags are different because my newly built binutils defaults to aslr + dep so no need for the extensive list in LDFLAGS.
Sadly while i could build all the dependencies gcc itself fails to bootstrap with the above error.

[jeremyd2019]

I decided to rebuild my compiler with alex patches 0300-default-secure-pe-flags.patch and 0310-reproducible-import-libraries.patch merged with the 0320-aslr-compat-base-addr.patch from latest pull and it works so far though im not completely sure about the fallthrough added in OPTION_DYNAMIC_BASE and OPTION_HIGH_ENTROPY_VA should also apply to the flags to set them to off. This has the added benefit that binutils will force aslr and dep by default even in bootstrapped gcc but it becomes interresting if it will also still break pch.

Those patches are not complete/sufficient. I just made a draft PR with the upstream patches cherry-picked if you would like to test with binutils with the new patches.

[jeremyd2019]

Only a new patch was added im not sure a rebuild has taken place yet as you need all dependant libraries to also be linked with aslr support.

I don't think you do. Each image (DLL or EXE) can be aslr or not, and there can be both in a process.

[revelator]

Hmm not from what i read but maybe they are wrong ?. Sure let me test it out :) so far i had no luck building either of binutils nor gcc with aslr and dep but several other packages build with no problem. So far i built libiconv gettext ncurses libtre libsystre winpthreads zlib bzip2 gmp isl mpfr and mpc without any problems with aslr and dep enabled.

I also implemented a more complete version of dlopen and friends from dlfcn-win32 for plugin support (works like a charm). Worst parts was figuring out where to yank in the psapi library as it needs that for enumerating process modules, it got a little hacky adding that but i could not find any autoconf varible specifically geared to handle this.

[jeremyd2019]

Hmm not from what i read but maybe they are wrong ?. Sure let me test it out :) so far i had no luck building either of binutils nor gcc with aslr and dep

Huh. GCC worked for me. I just successfully built mingw-w64-i686-python with gcc built with my #6899 patch to all gcc itself was built with the flags (minus ada libs).

[jeremyd2019]

I build the same list of packages you gave: libiconv gettext ncurses libtre-git libsystre winpthreads-git zlib bzip2 gmp isl mpfr mpc. Of these winpthreads didn't seem to take the LDFLAGS (so didn't have no-seh set). isl mpc and mpfr had no dlls or exes so there was no point in rebuilding those for these flags, which only apply to those. As always, this was all i686.

[jeremyd2019]

I rebuilt binutils and am currently building gcc. Using process explorer I set lower pane view to DLLs and turned on the ASLR, base, and image base columns. The only DLL I see in xgcc/cc1plus that is not ASLR is libzstd.dll. So far everything I've tried has worked for me on i686.

[revelator]

bug in gcc-9.3.0 maybe ? im still using the previous version.

[revelator]

so far i only tried building the x86_64 version, ill try with the i686 version next but it should have worked on either i reckon.

[revelator]

im at a loss... it simply does not work here :/

gcc is now wholly unable to find the crt, it crashes on avx512 instructions im not even able to rebuild the crt. Had to revert all the changes and call it a day.

It might have something to do with me using TDM's patchset for gcc which defaults it to using the static runtimes. I can build most other packages with aslr and dep though.

[mati865]

@revelator you also need patched binutils.

[revelator]

I know :) still unable to build gcc with aslr so im out of ideas.

[revelator]

Going to use a really old gcc (4.8.1) to bootstrap gcc-9.3.0 with aslr on. Just hope some of the later changes to binutils like the ctor changes dont wreak it. This time ill try without the TDM patchset but im not holding my hopes up just yet.

[revelator]

Nope still not possible to build gcc with aslr.

15958 |   __A = _mm512_mask_mov_ps (_mm512_set1_ps (1.0f), __U, __A);```

Same place again and this time building gcc-10.2.0.
Either something is horribly wrong with that avx function or i have no idea whats causing this.

[jeremyd2019]

GCC finished building fine for me. rebuild zstd as well to get everything gcc loads to be aslr, and that worked fine too. It looks like ICU doesn't take the LDFLAGS, but because I'm running the binutils with the updated defaults that just means --no-seh is not set (but for those attempting to test without binutils with new defaults, that would matter).

[revelator]

now im getting that error without setting aslr and dep even with Msys2 from the official installer Oo what on earth is going on.

[revelator]

There was actually a bug in the compiler intrinsics...

extern __inline double __attribute__ ((__gnu_inline__, __always_inline__, __artificial__)) _mm512_mask_reduce_mul_pd (__mmask8 __U, __m512d __A) { /* The intrinsics for _mm512_set1_pd must not have decimals behind */ __A = _mm512_mask_mov_pd (_mm512_set1_pd (1.0 <- yes this one), __U, __A); __MM512_REDUCE_OP (*); }

and another for float values, after removing the decimal after 1 it compiles cleanly again. Looks like some recent changes to one of the dependencies now trigger a compiler fault on these functions.

[jeremyd2019]

It looks like ICU doesn't take the LDFLAGS, but because I'm running the binutils with the updated defaults that just means --no-seh is not set (but for those attempting to test without binutils with new defaults, that would matter).

looks like boost should be added to the list of packages that don't take LDFLAGS also.

For the record, #6899 and #6907 include a commit to make GCC respect LDFLAGS in later stages and in 'target' binaries, and differ in two different workarounds to disable dynamicbase on the GCC backends so PCH works again.

[revelator]

Aye noticed you added more patches, trying them out now though i had to revert my build environment to an older version cause something has completely broken this one (throws internal compiler errors on everything).

[revelator]

Ok i think i found the problem breaking my builds. my bootstrap compiler used older versions of winpthreads gmp isl mpfr and mpc which caused the internal compiler errors when i updated my bootstrap compiler with it. Had to copy the old dll dependencies to where cc1.exe is located then bootstrap the compiler linking to the new gmp to hopefully get a working compile (atleast it is still building).

[revelator]

Yep that was it i just updated gmp on my working bootstrap compiler and gcc goes boom :S

[jeremyd2019]

There was actually a bug in the compiler intrinsics...

extern __inline double __attribute__ ((__gnu_inline__, __always_inline__, __artificial__)) _mm512_mask_reduce_mul_pd (__mmask8 __U, __m512d __A) { /* The intrinsics for _mm512_set1_pd must not have decimals behind */ __A = _mm512_mask_mov_pd (_mm512_set1_pd (1.0 <- yes this one), __U, __A); __MM512_REDUCE_OP (*); }

and another for float values, after removing the decimal after 1 it compiles cleanly again. Looks like some recent changes to one of the dependencies now trigger a compiler fault on these functions.

https://github.com/msys2/MINGW-packages/pull/6907/checks?check_run_id=1068095373#step:5:5741

Whoops!

[jeremyd2019]

Well that worked around that segfault, but now crashing trying to compile __mulxc3. Something is really screwy on x86_64.

[jeremyd2019]

I tried undoing the various changes to binutils options until I found what was causing this. Even without the patch to avx512fintrin.h, the build has gotten past the stage1 libgcc by setting --image-base=0x400000. This of course would suck if applied to any DLLs. My previous experimentation showed that these flags get applied to only one DLL, liblto_plugin-0.dll. I'll have a look and see if I can do something about that.

[revelator]

indeed i saw the same as the compile moved on.

ugh i had a hunch that it might relate to the lto plugin... could it be caused by the dlsym wrapper mechanism ? since i have a feeling this might balk out if it cannot read the base adress.

[jeremyd2019]

no, the crash is not related to LTO plugin... what the LTO plugin is doing now is making me have to try to come up with a workaround just for it

[revelator]

Got plenty confusing indeed with the various build errors, some seemed related to the dependency libraries others where just plain confusing like the avx512 error (since i had no problems compiling it with earlier binutils, but even downgrading it to the privious release ended up throwing the same error so i was like WTF).

But seems you have an idea about what might be causing it so ill let you work.

[jeremyd2019]

Yeah, I found a configure argument that should do what I want, but I'm in quoting hell right now trying to figure out what combination of quotes and escapes will get the string I want through to where I want it 😬

[revelator]

maybe alex or one of the other members got an idea for that ?.

[jeremyd2019]

Think I've got it. Hopefully https://github.com/msys2/MINGW-packages/pull/6907/commits/1c41e8edde85426dae4a2c6a651e2836816a00e5 does the trick. I couldn't get any quoting passed through to do what I wanted, so ultimately just escaped the spaces in LDFLAGS. This also happens to be the way the GCC docs demonstrate using this configure option (but for setting CC rather than LDFLAGS).

[jeremyd2019]

BTW, the only reason the base address should cause GCC crashes is what Microsoft referred to as 'latent pointer truncation issues'. So there's a bug somewhere in GCC, and this is just hiding it again.

[revelator]

ouch thats a nasty one...

[revelator]

got past stage 1 with the new build options though strangely stage 1 had aslr and dep disabled it is now running stage 2 which seems to have it enabled so im curious to see what happens when it hits libgcc since that is where the trouble seems to start.

[revelator]

stage 2 has succeded going for the home stretch 👍 hope to god there will be no further whoopsies down the lane. curious if it will still break gobject introspection.

[revelator]

agh libada segfaulted in the last stage, might be because i let the jobserver run with more than one core TDM gcc does not like that very much when bootstrapping gcc so ill have to do it all over again with make -j1 to make sure.

[revelator]

Well it still crashes building gnat tools so theres a bit more work needed i reckon.

rm -f tools/*
rm -rf tools
mkdir -p tools
(cd tools; ln -s ../sdefault.adb ../snames.ads ../snames.adb .)
rm -f tools/indepsw.adb; ln -s /G/mingw-w64-gcc/src/gcc-9.3.0/gcc/ada/indepsw-gnu.adb tools/indepsw.adb;
touch ../stamp-tools
../../gnatmake -j0 -c -b -I- -I../rts -I. -I/G/mingw-w64-gcc/src/gcc-9.3.0/gcc/ada \
  --GNATBIND="../../gnatbind" --GCC="../../xgcc -B../../ -g -march=x86-64 -mtune=generic -O2 -pipe -W -Wall  -gnatpg -gnata" \
  gnatchop gnatcmd gnatkr gnatls gnatprep gnatxref gnatfind gnatname \
  gnatclean -bargs -I- -I../rts -I. -I/G/mingw-w64-gcc/src/gcc-9.3.0/gcc/ada -static -x
make[3]: *** [../gcc-interface/Makefile:438: common-tools] Segmentation fault
make[3]: Forlader katalog "/G/mingw-w64-gcc/src/build-x86_64-w64-mingw32/gcc/ada/tools"
make[2]: *** [Makefile:197: gnattools-native] Fejl 2
make[2]: Forlader katalog "/G/mingw-w64-gcc/src/build-x86_64-w64-mingw32/gnattools"
make[1]: *** [Makefile:14037: all-gnattools] Fejl 2
make[1]: Forlader katalog "/G/mingw-w64-gcc/src/build-x86_64-w64-mingw32"
make: *** [Makefile:1006: all] Fejl 2```

the other libs seem to compile fine.

[jeremyd2019]

Huh, it built in CI... But, I have found that most gnat tools are built with LDFLAGS_FOR_TARGET rather than LDFLAGS/--with-boot-ldflags, so they would still be having the high base address.

[revelator]

it went pretty far here also (bootstrap done) but crashed both times at the same place in gnattools. Yeah i also noted that the executables had nxcombat and high entropy set but no aslr :S might be nice to get the gcc devs in over this one as well so we can avoid to many hacks.

[revelator]

And sorry if some of the messages look odd (im danish) and gettext (correctly) changed the compiler languages to that.

[jeremyd2019]

Yeah i also noted that the executables had nxcombat and high entropy set but no aslr :S

That shouldn't happen. The binutils will turn off high-entropy-va if dynamicbase is set, and will turn dynamicbase on if high-entropy-va is set.

[revelator]

Aye its pretty weird but that was what peviewer told me.

[revelator]

Hmm seems depot-tools and miktex together made some ugly broken environment i removed both and it builds normally now. Kinda sad though cause with miktex sourced i could build all documentation in gcc binutils and pretty much 90% of any other package.

[revelator]

spoke to soon gcc bootstrap still aint working not even if i revert the dep and aslr changes to binutils-2.35 internal compiler error galore. Not sure how but this experiment has rendered my compiler unusable i cannot build even the simplest things anymore. i even tried bootstrapping gcc on the official compiler and while it builds there as soon as i install it everything breaks again Oo.

[jeremyd2019]

I have no idea what's going on with your env 😕 The internal compiler errors seemed to be solved for me by changing the base address of the gcc executables back down below 4GB.

[mati865]

@jeremyd2019 this might be the same issue as in https://github.com/msys2/MINGW-packages/pull/6932#issuecomment-688233761 Does GCC use dllimport/dllexport for its own code?

[jeremyd2019]

Could be. I have no idea what GCC does.