LINUX.ORG.RU

Stack Smashing Protection >=GCC 4.8.3 на десктопе можно отключить?

 , ,


0

3

Компильнул gcc-4.8.3, в новостях пришло, что SSP теперь включено по дефолту и за это немножко нужно будет заплатить производительностью:

Beginning with GCC 4.8.3, Stack Smashing Protection (SSP) will be
enabled by default.

SSP is a security feature that attempts to ...

There is a small performance cost to these features.  They can be
disabled with -fno-stack-protector.

На десктопе это не так важно в плане безопасности, кто отключал, а кто оставил? Есть большое желание отключить.

В случае gentoo based CFLAGS="-O2 -march=native -fno-stack-protector" в make.conf.

Я не парюсь на эту тему. Мне быстродействия и так достаточно.

Jameson ★★★★★
()

еще -U_FORTIFY_SOURCE

нужно забенчить

anonymous
()

В плане производительности почти не влияет. Флага nossp нет?

Приеду, посмотрю как включал.

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

В плане производительности почти

в плане производительности, как говорят разработчики, нужно будет немножко пожертвовать в плане производительности, но нужно ли мне эта опция, если у меня не безоспасный сервер, где это может проявится, а обычная рабочая станция.

Флага nossp нет?

где нет? у меня сейчас:

CFLAGS="-march=bdver2 -O2 -pipe"
ставлю:
CFLAGS="-march=bdver2 -O2 -pipe -fno-stack-protector"

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

CFLAGS="-march=bdver2 -O2 -pipe -U_FORTIFY_SOURCE -fno-stack-protector
собирай так, чтобы наверняка. По дефолту там вроде бы двойка тоже.

wakuwaku ★★★★
()

На десктопе это не так важно в плане безопасности

Э... ты уверен? На десктопе, где ты пользуешься не стабильными и хорошо протестированными версиями программ, а фиг знает чем, SSP и прочие меры безопасности со стороны компилятора даже важнее, чем на сервере.

Кроме того, снижение производительности должно быть мизерное. Защита стека активируется только для некоторых функций и состоит в помещении одного дополнительного значения в стек и его проверке перед возвратом из функции.

proud_anon ★★★★★
()
Ответ на: комментарий от deterok
[1] x86_64-pc-linux-gnu-4.8.3 *

да вот тут выше посоветовали всё-таки не выключать, но я попробую как-нибудь сравнить, если время будет.

Включаю/выключаю через CFLAGS.

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

на критичных к производительности отключи, для всей системы оставь, как пацаны делают

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

что за глупости ты постишь? где там в gcc-config что отключать? зачем собирать с nossp? чтобы сборка отвалилась с ошибкой о неизвестных опциях, если где-то таки заданы опции -fstack-protector?

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

кстати забенчил опции preempt и hz в ядре на его же компиляции в 4ht потока:

preempt 1000hz
real  2m17.590s
real  2m17.759s
real  2m19.693s

server 1000hz
real  2m17.381s
real  2m17.543s
real  2m18.693s

server 100hz
real  2m14.696s
real  2m14.971s
real  2m16.905s
кто там что кукарекал, что пересборка ядра ничего не даёт?

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

4ht -> 4ре, никаких hyperthreading не имелось в виду

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

Это настолько очевидный и ожидаемый результат… Ты зря потратил своё время. Кстати попробуй теперь посмотреть динамичное fullhd видео (h264) с server 100hz ядром, мне интересно, что получится. Не забудь CONFIG_NO_HZ отключить.

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

Содержит только когда собран hardened-toolchain (и то это по идее относится только к самому тулчейну и возможно дефолтам, а не к пользовательским флагам), но не в нормальной ситуации, когда используется 1 компилятор для всего.

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

очевидный и ожидаемый результат

иисус кому-то тоже очевиден. а кодер x264 работает быстрее с 1000hz ядром, например

попробуй теперь посмотреть динамичное fullhd видео (h264

смотрю, всё как обычно

Не забудь CONFIG_NO_HZ отключить.

а от этого падает производительность, правда бенчил раньше

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

а кодер x264 работает быстрее с 1000hz ядром

это тоже ожидаемо, например

падает производительность

без NO_HZ не интересно, ты вероятно сможешь смотреть видео с NO_HZ, да.

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

без NO_HZ не интересно

загрузился с nohz=off, в perf top в первой строчке apic_timer_interrupt

видео как игралось, так и играется. ась?

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

Это как-то связано с таймером прерываний в ядре (и различной степенью утилизации ресурсов), увы я не разбираюсь в подсистемах ядра в достаточной мере, чтобы сказать конкретней. Кстати ещё можно поэкспериментировать с clocksource (tsc hpet acpi_pm и тд), это более интересно. Например jiffies давал лучший результат, чем pit и оба были лучше tsc.

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

У меня просмотр фуллхд видео утилизирует 1 ядро процессора почти полностью, ты что-то делаешь не так. Может быть плохо сжато, или смотришь через vdpau etc.

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

кстати на компиляции ядра c nohz=off таки не медленнее

real  2m14.510s
real  2m14.937s
real  2m16.849s

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.