зачем это, если есть ":(){ :|: & };:"? Делает то же самое, и, я думаю - быстрее.

> все файловые дескрипторы

А ulimit -n не спасает? По ссылке не ходил :)

derlafff> :(){ :|: & };:

От любого пользователя?

>> зачем это, если есть ":(){ :|: & };:"? Делает то же самое, и, я думаю - быстрее.

И легко убивается OOM ;)

Патч для устранения данной проблемы уже

Что и требовалось доказать.

да

Патч не устраняет проблему:

Hmm... it seems its another problem, chains are very long so we hit a NMI watchdog.

I guess we should limit to a very small number, like 64, or rewrite the garbage collector to a better algo.

http://lkml.org/lkml/2010/11/25/43

Говорит же вам Шишкин про алгоритмы и про МГИМО. Не хотите слушать - жрите, жрите это linux-way говно.

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

Опубликован, но не работает: «Hmm... it seems its another problem, chains are very long so we hit a NMI watchdog. I guess we should limit to a very small number, like 64, or rewrite the garbage collector to a better algo.»

мы все умрем

как я понял — нет :)

А вот и конец жизненного пути linux :)

> А ulimit -n не спасает?

Simple kernel attack using socketpair. easy, 100% reproductiblle, works under guest. no way to protect :(

See source attached.

Process become in state 'Running' but not killalble via kill -KILL.

eat 100% CPU, eat all available internal file descriptors in kernel :(

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

Патч не от той проблемы. Вчера независимо двумя разными людьми были обнаружены две не связанные друг с другом проблемы с socketpair().

Вот одна (от которой патч): http://lkml.org/lkml/2010/11/23/395

Вот вторая (без патча): http://lkml.org/lkml/2010/11/25/8 и http://www.spinics.net/lists/netdev/msg147904.html

зачем это, если есть ":(){ :|: & };:"? Делает то же самое, и, я думаю - быстрее.

это уже поборено давным давно

# ulimit -u 30

# ulimit -a

…

max user processes (-u) 30

…

http://www.gentoo.org/news/en/gwn/20050808-newsletter.xml#doc_chap6

> пустые циклы тоже сжирают 100 ресурсов, только никто еще не догадался патч написать.

пустые циклы можно убить через -KILL

> был обнародован код, позволяющий через вызов функции ядра socketpair() создать процесс, съедающий 100% процессорного времени и все файловые дескрипторы.

Сразу есть захотелось. Так аппетитно написано! Пойду на кухню.

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

жесть

Надеюсь это немного отрезвит горячего финского парня. Как говорится горькая правда иногда лучше чем сладкая ложь. А то у него синдром имени товарища Сталина - «головокружение от успехов»

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

Вот это даже и не ожидали...

Кстати да. Надо мной уже виндузятники смеются. В Линухе дыр говорят больше чем в семерке. Да еще таких, которые забодают на ровном месте.

Помню какую-то книгу читал... Хакеры ядра... Лучшие из лучших...

>Пробный патч, который, тем не менее, не устраняет проблему

Тонкий психологический ход, что бы сильно нервы не трепать.

Не удивлюсь если Линус прибежит к старику Столману со словами: «Отец, прости засранца! Давай пилить gnu/mach! :'(»

Говорил я где-то в толксах про модульную архитектуру ядра...

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

$ uname -a

Linux arch 2.6.36-ARCH #1 SMP PREEMPT Sun Oct 31 07:51:30 UTC 2010 i686 Intel(R) Celeron(R) CPU 2.53GHz GenuineIntel GNU/Linux

внезапно. Ждем еб^W патчей.

> Давай пилить gnu/mach!

нет уж, в морг - значит в морг

Не знаю кто как, а я не запускаю непроверенный код на своей машине.

а почитать его не судьба?

Это заговор.

Говорил я где-то в толксах про модульную архитектуру ядра...

А можно исходники глянуть?

>Не знаю кто как, а я не запускаю непроверенный код на своей машине.

категорически плюсую!
З.Ы. дырка забавная.

Программа по ссылке успешно грохает не только Linux, но и FreeBSD 8.1. Kernel panic :(

> Говорит же вам Шишкин про алгоритмы и про МГИМО. Не хотите слушать - жрите, жрите это linux-way говно.

Д'Артаньян, перестаньте нести чушь. Проблема с unkillable-процессами - родимое пятно Unix, и давно известна. Никаких особых знаний алгоритмов здесь не требуется.

парад локальных уязвимостей! когда удалённые начнутся?

И что ты там говорил?

Тоже запустил, пробовал убить сделать ренайс, не помогло. Само не сдохло. Разумеется, тормозит сильно, но в консоли можно спокойно работать.Пришлось делать ребут. Но ничего не поломалось после этого.

uname -a Linux mydoom 2.6.35-23-generic #40-Ubuntu SMP Wed Nov 17 22:14:33 UTC 2010 x86_64 GNU/Linux

> Программа по ссылке успешно грохает не только Linux, но и FreeBSD 8.1. Kernel panic :(

Забыл сказать, что пришлось заменить SOCK_SEQPACKET на SOCK_DGRAM

ждем ебилдов

Чем оно лучше 12309?

Чем оно лучше 12309?

Можно врубать в любое время.

>парад локальных уязвимостей!
плакал и смеялся

> Никаких особых знаний алгоритмов здесь не требуется.

Там сборка мусора в ядре облажалась. И даже если запускать ее раньше, чем закончатся ресурсы, ей нужно слишком много времени. Потому что писало её безграмотное быдло, которое считает, что «особых знаний алгоритмов не требуется».

Вот сейчас yaourt -Suy запустил, ядро обновилось, может, пофиксили?

>Потому что писало её безграмотное быдло, которое считает, что «особых знаний алгоритмов не требуется».

Так возьми да исправь, о великий знаток алгоритмов.

Ну так напишите лучше. Чего здесь-то кричите? Кому вы свою крутость показываете? Тому же выдлу, которого здесь ower 90 %?

И что ты там говорил?

Что Андрюша Таненбаум прав.

Собутыльник Танненбаума в треде!

>но и FreeBSD 8.1

А в виндах и макоси случаем не бсдшный сетевой стек?