Q: Антон, уже несколько дней как вышел clang15, а ты ничего про это не написал. Даже на opennet уже новость висит!!! https://www.opennet.ru/opennews/art.shtml?num=57739

A: В гробу я видел этот ваш пятнадцатый clang Я этот ваш clang пытаюсь завести еще с rc1, и это самый всратый релиз ever. Там включили несколько новых warning, несколько warning подняли до ошибок, некоторые новые фичи бажат, и, в результате, на выходе мы имеем несобирающуюся, кривую и косую, систему. Давайте я просто на нескольких примерах:

* "Для систем на базе архитектуры x86 добавлен флаг "-fzero-call-used-regs", обеспечивающий обнуление всех использованных в функции регистров CPU перед возвращением управления из функции. Указанная опция позволяет защититься от утечки информации из функций и примерно на 20% сократить число блоков, пригодных для построения ROP-гаджетов" #ROP

openssh определяет эту опцию, включает, и мы получаем посыпавшиеся бинари:

-checking if clang supports compile flag 
  -fzero-call-used-regs=all... yes
+checking if clang supports compile flag 
  -fzero-call-used-regs=all... no

make: *** [Makefile:451: host-key] Segmentation fault

* clang теперь отказывается звать функции без ее предварительного определения, и отказывается(в некоторых контекстах) от default int. Беда-беда, но configure скрипты завязаны на это, но вместо их падения мы получаем кучу misconfigure в разном софте:

-checking if setresuid seems to work
 ... not implemented
+checking if setresuid seems to work
 ... yes

-checking whether fpurge works... yes
+checking whether fpurge works... no

-checking if openpty correctly 
 handles controlling tty... no
+checking if openpty correctly 
 handles controlling tty... yes

-checking for sighandler_t... no
+checking for sighandler_t... yes

Да тысячи их. coreutils получаются условно-работающие.

* 19 мая я писал про https://discourse.llvm.org/t/rejected-rfc-stop-defining-the-stdc-and-related-macros-in-c-mode/62468/3

Кажется, оно выстрелило, потому что часть configure скриптов перестала находить правильные размеры для ptrdiff_t, size_t, etc.

configure:20525: clang -c   conftest.c >&5
.[1mconftest.c:86:17: .[0m.[0;1;31merror: .[0m.[1m
expected expression.[0m
if ((ptrdiff_t *) 0)
.[0;1;32m                ^
.[0m.[1mconftest.c:86:6: .[0m.[0;1;31merror: .[0m.[1m
use of undeclared identifier 'ptrdiff_t'.[0m
if ((ptrdiff_t *) 0)
.[0;1;32m

Я это свел вот к таком коду:

| #if STDC_HEADERS
| # include <stdlib.h>
| # include <stddef.h>
| #else
| # if HAVE_STDLIB_H
| #  include <stdlib.h>
| # endif
| #endif

Попытка запретить часть из этих warning тоже ни к чему хорошему пока не привела - ломаются уже другие части этих сраных configure скриптов.

19 же мая я писал, что коллеги из clang осмелели, и решили больше отступать от канвы gcc так, как они считают нужным. Видимо, Остапа понесло...

#stal/ix #security #ROP

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

Возьмем, например, https://en.wikipedia.org/wiki/Return-oriented_programming

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

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

func1:
...
A
B
ret

func2:
...
C
D
ret

Вот, можно так аугментировать call stack, что будет выполнено:

A
B
ret
C
D
ret
...

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

Количество реюзабельных кусочков пропорционально общему объему кода программы.

Поэтому, как ни странно, статическая линковка, за счет того, что линкер выкидывает неиспользуемые функции, дает меньше строительных материалов для атаки, нежели когда ты в себя влинковал кучу мертвого кода из кучи .so (суммарный объем всех .so для почти любой программы, конечно, больше, чем та же программа, но слинкованная статически).

А, значит, "более безопасна"!

https://github.com/rui314/mold/releases/tag/v2.3.0

Вышел новый #mold.

Вполне обычный релиз, в changelog глаз зацепился за

"mold 2.3.0 has introduced an experimental flag, -z rewrite-endbr, which rewrites superfluous endbr64 instructions as nop"

Полез смотреть, что это за инструкция, https://stackoverflow.com/questions/56905811/what-does-the-endbr64-instruction-actually-do - вполне норм описание, с выдержками из арх. мануалов, и все такое.

Прикольная штука, насколько я понимаю, она делает #ROP почти obsolete.

А вы знали? Я не знал!