(троллоло) Решето GCC

Что-то всё больше складывается впечатление, что GCC не нужен...

рекомендую использовать -march=native -mtune=native -O99 -pipe -mmmx -msse -msse2 -msse3 -mssse3 -m3dnow -mfpmath=sse,387 -maccumulate-outgoing-args -msseregparm -minline-stringops-dynamically -fomit-frame-pointer -funsafe-loop-optimizations -ftracer -g0 -s -fmerge-all-constants -fira-region=one -fprefetch-loop-arrays -fforce-addr -fpeel-loops -ftree-loop-im -fsee -fsched-spec-load-dangerous -fsched2-use-superblocks -frename-registers -fivopts -fgcse-las -fgcse-sm -ftree-loop-linear -floop-interchange -floop-strip-mine -ftree-loop-distribution -ftree-loop-im -ftree-loop-ivcanon -fvect-cost-model -fvariable-expansion-in-unroller -fselective-scheduling2 -fsel-sched-pipelining -fsel-sched-pipelining-outer-loops -fmodulo-sched -freschedule-modulo-scheduled-loops -fmodulo-sched-allow-regmoves -fno-defer-pop -fno-ident -freorder-blocks-and-partition -fgcse-lm -fbtr-bb-exclusive -fira-coalesce -ffast-math -fno-math-errno -funsafe-math-optimizations -combine -funroll-loops -fgraphite-identity -floop-parallelize-all флаги для сборки vim!

Давайте напишем едро на православной жабе? :-)

Опять небось эксплойт фиг запустишь...

gcc улучшается, кривой код и уязвимый код из ведра выкидывается, одни плюсы же :)

До чего же журналюги тупые, даже если они от фри софтваре. Во-первых, баг в ядре, gcc здесь не причем. Во-вторых, недавно был похожий баг (опять же в ядре, в tun подсистеме), и там действительно gcc убирал проверку на NULL (это документировано, и убирать такие проверки он будет в дальнейшем). Читайте оригинальное сообщение - http://permalink.gmane.org/gmane.comp.security.full-disclosure/68951, посмотрите код и подумайте головой (хинт: проверки там никакой нет, и убирать ее некому).

На опееннете ошиблись. Из-за оптимизации, сделанной GCC, ошибка проявлялась в драйвере TUN/TAP-интерфейса. Причём (ещё раз повторяю), это было ошибка в драйвере, GCC всё сделал правильно.

А эта ошибка (новая) к GCC вообще никакого отношения не имеет. Тут просто проверку на NULL забыли.

> До чего же журналюги тупые, даже если они от фри софтваре. Во-первых, баг в ядре, gcc здесь не причем. Во-вторых, недавно был похожий баг (опять же в ядре, в tun подсистеме), и там действительно gcc убирал проверку на NULL (это документировано, и убирать такие проверки он будет в дальнейшем). Читайте оригинальное сообщение - http://permalink.gmane.org/gmane.comp.security.full-disclosure/68951, посмотрите код и подумайте головой (хинт: проверки там никакой нет, и убирать ее некому).

Опередил =).

> рекомендую использовать ... флаги для сборки vim!

Чорт.

> Давайте напишем едро на православной жабе? :-)

Тогда сначала придётся правильную жабу написать...

Для Ъ - это трижды по тридцать раз порванный боян об уязвимости в TUN/TAP, для эксплойта которой нужен криво спроектированный SUID-бинарь?

Нет, теперь малиновы^W это уязвимость в сетевой подсистеме

> это уязвимость в сетевой подсистеме

А GCC тут причем? "the sock_sendpage() routine does not validate the function pointer is valid before dereferencing it", происходит выполнение кода по адресу NULL, и привет. Причем тут компилятор?

Ну и "recent kernels with mmap_min_addr support may prevent exploitation if the sysctl vm.mmap_min_addr is set above zero".

> Что-то всё больше складывается впечатление, что Линупсь не нужен...

fxd

>Ну и "recent kernels with mmap_min_addr support may prevent exploitation if the sysctl vm.mmap_min_addr is set above zero".

что как бы всё равно не отменяет

>>уязвимости остаются подвержены все выпущенные с 2001 года версии ядра, включая 2.6.30.4.

А GCC похоже не при делах, да

> Что-то всё больше складывается впечатление, что Линупсь не нужен...

>fxd

И такое впечатление тоже складывается, но пока ещё интересно.

посмотрел патч, gcc там убрал проверку на null прям из исходников ?

> посмотрел патч, gcc там убрал проверку на null прям из исходников ?

:D GCC настолько суров...

Глюк не проявляется на наиболее распространённых протоколах.

Эээ… это не тот баян, что на главной был как-то?

а для сплойта опять нужен пульс, ага? )

>Давайте напишем едро на православной жабе? :-)

а жабу чем собирать? скинемся на интеловый компилер?

>Из-за оптимизации, сделанной GCC, ошибка проявлялась в драйвере TUN/TAP-интерфейса. Причём (ещё раз повторяю), это было ошибка в драйвере, GCC всё сделал правильно.

+много.

>Ну и "recent kernels with mmap_min_addr support may prevent exploitation if the sysctl vm.mmap_min_addr is set above zero".

а вот за это спасиб. а то там на глагне человек слюной исходил что только виндавс так умеет.

Ни одна программа или железяка не выдержит напора пидарасов.

>>Давайте напишем едро на православной жабе? :-)

> а жабу чем собирать? скинемся на интеловый компилер?

Проблема не в том, как компилировать java классы.

Чтобы писать систему на java нужно, чтобы система выполняла class файлы напрямую.

Также нужно понятие "задачи" что-то вроде "индивидуальной кучи мусора" для каждой отдельной задачи.

Также должна быть возможность запускать отдельные задачи без сборки мусора вообще (в этом стиле должны быть написаны части системы требующие гарантированного быстродействия).

Также в java:

Отсутствуют типы unsigned byte, unsigned int, unsigned long.

Отсутствует возможность typedef.

Отсутствует понятие структур и битовых полей.

Максимальный размер массива ограничен типом int.

В общем, чтобы переписать любую вещь с языка C на Яву приходится сильно попотеть.