LINUX.ORG.RU

Можно ли MinGW считать компилятором?

 , , ,


0

2

Недавно решил сравить qsort на разных Windows компиляторах. MinGW сделал это быстрее всех. Это показалось странным, учитывая что это-то C шная функция, а MinGW использует для C функций Microsoft библиотеку. Дело в флагах. Какие есть флаги безопасности у MinGW:

Защита стека

-fstack-protector-all --param ssp-buffer-size=4 -fstack-check
Аналог у MSVC(https://msdn.microsoft.com/en-us/en-en/library/8dbf701c.aspx):
/GS

DEP

-Wl,--nxcompat
Аналог у MSVC(https://msdn.microsoft.com/en-us/en-en/library/ms235442.aspx)
/NXCOMPAT

ASLR

-Wl,--dynamicbase
Аналог у MSVC(https://msdn.microsoft.com/en-us/en-en/library/bb384887.aspx)
/DYNAMICBASE

64 bit для ASLR(только для 64 битных программ)

-Wl,--high-entropy-va
Аналог у MSVC(https://msdn.microsoft.com/en-us/en-en/library/jj835761.aspx)
/HIGHENTROPYVA

Но у MSVC есть ещё один флаг для защиты Enable Control Flow Guard(https://msdn.microsoft.com/en-us/en-en/library/dn919635.aspx)

/guard:cf
Этого флага нет у MinGW.

Аналог этого на Linux:

https://pax.grsecurity.net/docs/PaXTeam-H2HC15-RAP-RIP-ROP.pdf

https://wiki.gentoo.org/wiki/Hardened/PaX_Quickstart

Вот ещё нашел статейку про Enable Control Flow https://habrahabr.ru/company/dsec/blog/305960/

Вот сейчас пытаюсь разобраться насколько это увеличивает безопасность, а то может пора выкидывать MinGW и самому компилировать ядро Linux для включения PaX...

Если кто-то уже разбирался с этой темой, то прошу поделиться к каким выводам вы пришли...

Защита стека и control flow guard это единственное из списка, что требует особых действий в компиляторе, остальное — флаги в PE. Так что сравнение очень странное.

Можно ли MinGW считать компилятором?

Можно, конечно. Недоразумение от M$ не умеет в C99 и либо всё ещё не научилось, либо только несколько месяцев как может two-phase lookup из C++98.

xaizek ★★★★★ ()
Ответ на: комментарий от xaizek

Просто после того кого как наткнулся на это, посмотрел на другие компиляторы и выходит, только MinGW на текущий момент не поддерживает Flow Control... Или предыдущих методов защиты достаточно для приложений, и Flow Control тоже обходится хакерами, поэтому плохо что нет, но это не повод сменить компилятор?

Intel: https://software.intel.com/en-us/cpp-compiler-18.0-developer-guide-and-refere...

Clang: https://clang.llvm.org/docs/ControlFlowIntegrity.html

Если кто-то разбирался во флагах безопасности в gcc/mingw, то давайте сравним флаги

Вот мои:

Linux

CFLAGS_SECURITY = -D_FORTIFY_SOURCE=2 -fPIE -fstack-protector-all --param ssp-buffer-size=4 -fstack-check -Wa,--noexecstack
LD_SECURITY = -pie -Wl,-z,relro,-z,now -Wl,-z,noexecstack

MinGW

CFLAGS_SECURITY = -fstack-protector-all --param ssp-buffer-size=4 -fstack-check
LD_SECURITY = -Wl,--dynamicbase -Wl,--nxcompat
ifeq ($(BITS),64)
    LD_SECURITY += -Wl,--high-entropy-va
endif
LIBS += -lssp

fsb4000 ()
Ответ на: комментарий от fsb4000

Ну сейчас нет, потом может притянут -fcf-protection==[full|branch|return|none] из нового GCC, хотя оно на Intel CET и я не знаю, где оно доступно. Мир не рухнет, если какой-то меры безопасности не будет, так как это не панацея в любом случае и не нужно его пихать во все дыры.

xaizek ★★★★★ ()
Последнее исправление: xaizek (всего исправлений: 1)
Ответ на: комментарий от xaizek

вообще на маздае, где дыры и утечки в самой системе, говорить о безопасности софта как-то странно. какой смысл проверять стек в приложении, если сама система дырявая и кривая? я пока работала с маздаем, видела утечки и сегфолты в libc и математических библиотеках. причём мелкософт о них знал и по многу лет ничего не предпринимал. так что все эти мелочи не спасут от хакера, если это действительно хакер, а не просто школьник на каникулах.

Iron_Bug ★★ ()