1.2, gegMOPO4 (ok), 17:54, 25/11/2010 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Что, в ядре и вправду используются конструкции вида gc_in_progress == false?!
| |
|
|
3.5, JL2001 (ok), 18:07, 25/11/2010 [^] [^^] [^^^] [ответить]
| +2 +/– |
> Для временного решения проблемы можно...
судя по отсутствию +сика перед строкой - это строка не во временном патче
| |
|
|
1.4, JL2001 (ok), 18:05, 25/11/2010 [ответить] [﹢﹢﹢] [ · · · ]
| –4 +/– |
к вопросу о гарбаджколлекторе в сях - расскажите мне о ненужности сборщика мусора на мегакрутеньтру языках
| |
|
2.7, Аноним (-), 18:11, 25/11/2010 [^] [^^] [^^^] [ответить]
| +2 +/– |
> к вопросу о гарбаджколлекторе в сях - расскажите мне о ненужности сборщика
> мусора на мегакрутеньтру языках
Вы путаете язык и программу которая на нём пишется. Разберитесь чем одно от другого отличается.
| |
|
3.11, JL2001 (ok), 18:57, 25/11/2010 [^] [^^] [^^^] [ответить]
| –3 +/– |
>> к вопросу о гарбаджколлекторе в сях - расскажите мне о ненужности сборщика
>> мусора на мегакрутеньтру языках
> Вы путаете язык и программу которая на нём пишется. Разберитесь чем одно
> от другого отличается.
тоесть программы написанные на сях требуют ручками реализовывать разные гарбаджколлекторы ?
| |
|
|
5.14, JL2001 (ok), 19:54, 25/11/2010 [^] [^^] [^^^] [ответить]
| –12 +/– |
> то есть вы увидели в новости "garbage collector" и стали пороть чепуху.
а может чепуху пороли те кто говорил о ненужности каких либо сборщиков мусора в программах написанных на трусуперкрутьязыках ?
| |
|
6.15, anonymous (??), 20:07, 25/11/2010 [^] [^^] [^^^] [ответить]
| +8 +/– |
найденная уязвимость не имеет отношения к отсутсвию сборщика мусора в C. упоминаемая в коде программы "сборка мусора" тоже не имеет к этому отношения. с вашими комментариями проследуйте на лор пожалуйста.
| |
|
|
4.24, gegMOPO4 (ok), 21:43, 25/11/2010 [^] [^^] [^^^] [ответить]
| +3 +/– |
> тоесть программы написанные на сях требуют ручками реализовывать разные гарбаджколлекторы
> ?
Как и не на сях. Это совсем другой сборщик, он собирает совсем другой мусор.
| |
4.55, тоже Аноним (ok), 12:07, 26/11/2010 [^] [^^] [^^^] [ответить]
| +3 +/– |
> тоесть программы написанные на сях требуют ручками реализовывать разные гарбаджколлекторы?
С какого вдруг "требуют"? Сборщик мусора - технология, которая может быть использована хоть в ассемблере. Вы имеете в виду, что в низкоуровневых языках он не встроен в язык, как в Жабе или ДотНете? Да, не встроен, это общеизвестно. На чем написан сборщик в высокоуровневых языках - вы тоже не в курсе?
В одном вы правы - Си позволяет реализовать РАЗНЫЕ сборщики. А жабисты и дотнетчики вынуждены пользоваться одним, ОДИНАКОВЫМ ;)
| |
|
|
2.72, User294 (ok), 15:33, 26/11/2010 [^] [^^] [^^^] [ответить]
| +/– |
> к вопросу о гарбаджколлекторе в сях - расскажите мне о ненужности сборщика
> мусора на мегакрутеньтру языках
Ой. Тогда получается что файловые системы с гарбаж коллектром - полное дерьмо? Заметьте, простую файловую систему с GC (например для NOR флеша) можно даже на гольном асме родить. В силу довольно простой логики сбора мусора в такой ФС и прочая.
Хинт: гарбаж колекторы не являются абсолютным злом сами по себе :). А вот когда их сватают как замену мозга - вот тут да, безмозглые програмеры это зло.
| |
|
1.8, fa (??), 18:11, 25/11/2010 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Поясните, в чем именно там проблема. Взял пользователь, да и исчерпал ресурс системы. Чем это отличается от for (;;) malloc(100500); ?
| |
|
2.9, FractalizeR (ok), 18:13, 25/11/2010 [^] [^^] [^^^] [ответить]
| +1 +/– |
Видимо тем, что ваш вариант должен убиваться по SIGKILL. Если успеть послать этот сигнал до того, как ядро его прибьет процесс, исчерпавший память.
| |
2.10, Аноним (-), 18:14, 25/11/2010 [^] [^^] [^^^] [ответить]
| +2 +/– |
> Поясните, в чем именно там проблема. Взял пользователь, да и исчерпал ресурс
> системы. Чем это отличается от for (;;) malloc(100500); ?
Тем что процесс можно убить, а тему новости — нет.
Тем что malloc тратит память польователя, а тема новости — ресурсы ядра.
| |
|
1.12, Zenitur (?), 19:12, 25/11/2010 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
pavlinux, пропатчил себе я ядро. У меня вопрос: может ли найтись экзотический сот, который с пропатченным ядром откажется работать? Или это исключено?
| |
|
|
3.48, ta (??), 04:16, 26/11/2010 [^] [^^] [^^^] [ответить]
| +/– |
до socket restrictions дело так и не дошло... хватило tpe.
| |
|
|
|
2.31, Аноним (-), 23:05, 25/11/2010 [^] [^^] [^^^] [ответить]
| +2 +/– |
openvz имеет ограничение на количество unix socket внутри контекста, он спасает от этой атаки.
linux vserver вроде такого ограничения не имел - так что там эта атака пройдет на ура.
| |
|
1.19, Аноним (-), 21:13, 25/11/2010 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
мда, серьёзная штука, машину с четыремя ядрами кладёт через пару секунд в полный даун
| |
1.20, Аноним (-), 21:15, 25/11/2010 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
вообще подобного рода вещи, вроде, отправляются в закрытый список, занимающийся безопасностью в ядре
| |
1.22, Аноним (-), 21:29, 25/11/2010 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
че та нынче в линухе баг за багом и очень хорошо, если не рута получают, а просто систему кладут.
| |
|
2.30, Аноним (-), 22:35, 25/11/2010 [^] [^^] [^^^] [ответить] | +/– | вот так выглядит более правильно diff --git a include net af_unix h b include ne... большой текст свёрнут, показать | |
|
|
4.59, Аноним (-), 13:29, 26/11/2010 [^] [^^] [^^^] [ответить]
| +/– |
и загубишь все на корню - слишком глобальная эта ручка, а если в фиксе заменить за get_max_file() на NR_FILES просто ограничишь очередь сообщений до 8к. и все будет жить.
| |
|
5.64, pavlinux (ok), 14:06, 26/11/2010 [^] [^^] [^^^] [ответить]
| +/– |
> и загубишь все на корню - слишком глобальная эта ручка, а если
> в фиксе заменить за get_max_file() на NR_FILES просто ограничишь очередь сообщений
> до 8к. и все будет жить.
Не, там синтаксисеская обшибка
вместо
fs.files-max, надо
fs.file-max
| |
|
|
7.71, Аноним (-), 15:32, 26/11/2010 [^] [^^] [^^^] [ответить]
| +/– |
> ааа. это я полусонным рисовал по памяти.
> спасибо.
просто максимальное количество unix sockets это 2*get_max_files().
так что ddos тулза упрется в нее в конце концов - но системе станет хреново к тому моменту.
А потом exit_task -> put file struct - будет оооочень долгим ибо их дохрена.
| |
|
|
9.77, Аноним (-), 16:13, 26/11/2010 [^] [^^] [^^^] [ответить] | +/– | exit_task прервать нельзя - в этом code path нету мьютексов - только spinlock ... текст свёрнут, показать | |
9.89, h4tr3d (ok), 18:52, 26/11/2010 [^] [^^] [^^^] [ответить] | +/– | На своём EeePC 1000 при дефолтных сиречь моих рабочих настройках проверил fs ... текст свёрнут, показать | |
|
|
|
|
|
|
|
2.33, Аноним (-), 23:30, 25/11/2010 [^] [^^] [^^^] [ответить] | +/– | вобщем фикс действительно кривой проблема вот в чем 1 мы посылаем сообщение с ... большой текст свёрнут, показать | |
|
1.32, Buy (??), 23:30, 25/11/2010 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
Запустил, система тут же ушла в даун, даже на другой десктоп не смог переключиться (там был запущен top), минуты через три нажал reset, но комп не смог загрузиться - сработала система защиты на материнке (у меня такое когда-то случалось когда баловался с разгоном проца), потом ящик всёже загрузился с третьей попытки. Прикольно :)
| |
|
2.37, pavlinux (ok), 00:14, 26/11/2010 [^] [^^] [^^^] [ответить]
| +/– |
> Запустил, система тут же ушла в даун, даже на другой десктоп не
> смог переключиться (там был запущен top), минуты через три нажал reset,
> но комп не смог загрузиться - сработала система защиты на материнке
> (у меня такое когда-то случалось когда баловался с разгоном проца), потом
> ящик всёже загрузился с третьей попытки. Прикольно :)
Вы эта того, аккуратнее. В новости же написано, что работает!!! :)
| |
|
1.34, тигар (ok), 23:54, 25/11/2010 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
на самом деле полезная вещь - можно отапливать ЦОДы поставив туда стойки с линакс-машинами.
| |
|
2.75, User294 (ok), 15:52, 26/11/2010 [^] [^^] [^^^] [ответить]
| +/– |
> на самом деле полезная вещь - можно отапливать ЦОДы поставив туда стойки
> с линакс-машинами.
С *BSD такое тоже вполне катит, судя по коментам юзвергов тут и на хабре.
| |
|
3.81, Аноним (-), 16:28, 26/11/2010 [^] [^^] [^^^] [ответить]
| –1 +/– |
>> на самом деле полезная вещь - можно отапливать ЦОДы поставив туда стойки
>> с линакс-машинами.
> С *BSD такое тоже вполне катит, судя по коментам юзвергов тут и
> на хабре.
Проверил, у меня в FreeBSD 8.1, 7.3 и 6.4 не работает. Видимо комментаторы с хабра от рута тот экспоит запускали.
| |
|
|
1.40, pavlinux (ok), 00:47, 26/11/2010 [ответить] [﹢﹢﹢] [ · · · ]
| +3 +/– |
Прикол, Debian 6.0 в даун не ушёл, только матерился, что "too many open files",
и удалось корректно выключить через Кнопку "Выйти" на панели.
Всё, пипец!!! Это окончательный приговор SuSE :)
| |
|
|
3.63, fidaj (ok), 13:42, 26/11/2010 [^] [^^] [^^^] [ответить]
| +/– |
> как выполнить на freebsd?
> что-то не компилится...
replace SOCK_SEQPACKET on SOCK_DGRAM
| |
|
|
1.44, pavlinux (ok), 03:13, 26/11/2010 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Вобщам дела такие
# sysctl -w fs.file-max=84000 (где-то от 40000 до 90000)
Больше 200.000 появляются сильные тормоза, а при 500.000+ можно сказать зависон.
Приводит к возможности реакций на Ctrl-Alt-Fn, запуска консоли и kill -9
или корректного ребута.
Да, да, на kill -9 оно реагирует, но только минуты через 3 :)
| |
1.45, Аноним (-), 03:44, 26/11/2010 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Все линуксовые серваки своему хостеру положил. FreeBSD'шные стоят как ни в чем не бывало.
| |
|
2.46, pavlinux (ok), 03:45, 26/11/2010 [^] [^^] [^^^] [ответить]
| +/– |
> FreeBSD'шные стоят как ни в чем не бывало.
"Новый способ совершения локальной DoS-атаки в Linux"
Где ты слово FreeBSD увидел?
| |
|
3.47, Аноним (-), 03:53, 26/11/2010 [^] [^^] [^^^] [ответить]
| +/– |
А где я должен был его увидеть? В новости про уязвимость его разумеется нет.
| |
|
4.50, Аноним (-), 08:22, 26/11/2010 [^] [^^] [^^^] [ответить]
| +/– |
> А где я должен был его увидеть? В новости про уязвимость его
> разумеется нет.
Капитан, Вы?
| |
|
3.73, User294 (ok), 15:36, 26/11/2010 [^] [^^] [^^^] [ответить]
| +/– |
> "Новый способ совершения локальной DoS-атаки в Linux"
> Где ты слово FreeBSD увидел?
Наверное где-то в районе http://habrahabr.ru/blogs/linux/108835/ - там народ почему-то утверждает что и некоторые BSD таким манером кладутся (лично не проверял, однако судя по чертыханиям народа - вполне себе работает и на разных *BSD).
| |
|
2.49, Аноним (-), 08:21, 26/11/2010 [^] [^^] [^^^] [ответить]
| +2 +/– |
"сломал крякер своего провайдера, теперь сидит без интернета"
| |
2.52, oops (ok), 11:26, 26/11/2010 [^] [^^] [^^^] [ответить]
| +/– |
freebsd тоже подвержена, по крайней мере 8.1 релиз - точно. Только что в ребут ушла
| |
|
3.53, oops (ok), 11:36, 26/11/2010 [^] [^^] [^^^] [ответить]
| +/– |
только для BSD надо немного код изменить
добавить заголовочные файлы
#include <sys/mount.h>
#include <sys/wait.h>
#include <errno.h>
#include <fcntl.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
и заменить все SOCK_SEQPACKET на SOCK_DGRAM.
8.1-RELEASE без разговоров сразу в ребут =(
| |
|
4.54, oops (ok), 11:41, 26/11/2010 [^] [^^] [^^^] [ответить]
| +/– |
тьфу, столько заголовочных написал, не туда посмотрел. Хотя и так работать будет
| |
4.83, sacha (?), 17:03, 26/11/2010 [^] [^^] [^^^] [ответить]
| +/– |
>[оверквотинг удален]
> #include <sys/mount.h>
> #include <sys/wait.h>
> #include <errno.h>
> #include <fcntl.h>
> #include <stdio.h>
> #include <stdlib.h>
> #include <string.h>
> #include <unistd.h>
> и заменить все SOCK_SEQPACKET на SOCK_DGRAM.
> 8.1-RELEASE без разговоров сразу в ребут =(
Выставил sbsize в 393216 - перестало.
| |
|
5.84, Аноним (-), 17:40, 26/11/2010 [^] [^^] [^^^] [ответить]
| +/– |
> Выставил sbsize в 393216 - перестало.
и NFS перестала запускаться, и SSH отвалилось :-(
| |
|
6.85, sacha (?), 17:58, 26/11/2010 [^] [^^] [^^^] [ответить]
| +/– |
>> Выставил sbsize в 393216 - перестало.
> и NFS перестала запускаться, и SSH отвалилось :-(
У меня ssh не отвалилось.
nfs нету.
sbsize не на всех, а только на user-ов, через login.conf
На моей конфигурации тест отрабатывает 30 раз при таком значении и завершается.
| |
|
7.95, pavlinux (ok), 01:13, 28/11/2010 [^] [^^] [^^^] [ответить]
| +/– |
>>> Выставил sbsize в 393216 - перестало.
>> и NFS перестала запускаться, и SSH отвалилось :-(
> У меня ssh не отвалилось.
> nfs нету.
> sbsize не на всех, а только на user-ов, через login.conf
> На моей конфигурации тест отрабатывает 30 раз при таком значении и завершается.
Ну вы блин даёте! (с)
| |
|
|
5.91, Аноним (-), 23:24, 26/11/2010 [^] [^^] [^^^] [ответить]
| +/– |
Мне данная мера не помогла. Попробуйте запустить несколько процессов. У меня при sbsize=8M и лимите процессов в 24 тот же кернел паник.
| |
5.93, alvarez (?), 03:06, 27/11/2010 [^] [^^] [^^^] [ответить]
| +/– |
У меня FreeBSD 8.1-RELEASE-p1 - уходит в ребут.
В консоли светится:
kernel: Cannot dump. Device not defined or unavailable.
kernel: Automatic reboot in 15 seconds - press a key on the console to abort
Увеличил maxsockbuf до 393216 по рекомендации sacha (по дефолту - 262144)
# sysctl -w kern.ipc.maxsockbuf=393216
Тоже не помогло. Идеи?
| |
|
|
|
|
|
|
3.79, Аноним (-), 16:22, 26/11/2010 [^] [^^] [^^^] [ответить]
| +/– |
в фоках и дело :)
когда количество таких процессов становится > N_CPU то на exit_task будет уходить время всех процов - и это будет весело, без форка должно нормально жить на 2-4х CPU.
| |
|
|
1.58, прохожий (?), 13:28, 26/11/2010 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
по теме - протестил на том что было под руками: трабл подтвердился на Ubuntu 10.10 x86_64 и Debian 5.0.6 x86_64. на RHEL AS 4 U4 x86_64 не прокатило! видимо проблеме подверженны только ванильные ядра.
| |
|
2.65, pavlinux (ok), 14:16, 26/11/2010 [^] [^^] [^^^] [ответить]
| +/– |
> по теме - протестил на том что было под руками: трабл подтвердился
> на Ubuntu 10.10 x86_64 и Debian 5.0.6 x86_64. на RHEL AS
> 4 U4 x86_64 не прокатило! видимо проблеме подвержены только ванильные ядра.
Сможешь показать из Редхата АС 4
# sysctl -A | egrep 'gc_|fs.file|inode'
| |
|
3.67, прохожий (?), 14:42, 26/11/2010 [^] [^^] [^^^] [ответить]
| +/– |
держи
$ uname -rm
2.6.9-78.14.EL x86_64
$ cat /etc/redhat-release
Red Hat Enterprise Linux AS release 4 (Nahant Update 4)
$ sudo /sbin/sysctl -A | egrep 'gc_|fs.file|inode'
net.ipv6.neigh.eth0.gc_stale_time = 60
net.ipv6.neigh.lo.gc_stale_time = 60
net.ipv6.neigh.default.gc_thresh3 = 1024
net.ipv6.neigh.default.gc_thresh2 = 512
net.ipv6.neigh.default.gc_thresh1 = 128
net.ipv6.neigh.default.gc_interval = 30
net.ipv6.neigh.default.gc_stale_time = 60
net.ipv6.route.gc_elasticity = 0
net.ipv6.route.gc_interval = 30
net.ipv6.route.gc_timeout = 60
net.ipv6.route.gc_min_interval = 0
net.ipv6.route.gc_thresh = 1024
net.ipv4.neigh.eth0.gc_stale_time = 60
net.ipv4.neigh.lo.gc_stale_time = 60
net.ipv4.neigh.default.gc_thresh3 = 1024
net.ipv4.neigh.default.gc_thresh2 = 512
net.ipv4.neigh.default.gc_thresh1 = 128
net.ipv4.neigh.default.gc_interval = 30
net.ipv4.neigh.default.gc_stale_time = 60
net.ipv4.inet_peer_gc_maxtime = 120
net.ipv4.inet_peer_gc_mintime = 10
net.ipv4.route.gc_elasticity = 8
net.ipv4.route.gc_interval = 60
net.ipv4.route.gc_timeout = 300
net.ipv4.route.gc_min_interval = 0
net.ipv4.route.gc_thresh = 32768
fs.file-max = 98936
fs.file-nr = 1812 0 98936
fs.inode-state = 3222 266 0 0 0 0 0
fs.inode-nr = 3222 266
| |
|
4.68, pavlinux (ok), 14:51, 26/11/2010 [^] [^^] [^^^] [ответить]
| +/– |
> fs.file-nr = 1812 0 98936
> fs.file-max = 98936
Ну и понятно, с чего бы ей загнуться.
Хотя скорее дело не в этом. С версии 2.6.9+ много всего поменялось.
| |
|
|
|
1.86, Xaionaro (ok), 18:22, 26/11/2010 [ответить] [﹢﹢﹢] [ · · · ]
| +2 +/– |
Кхм... Почему-то я стал в "мини-новостях" находить интересные новости чаще, чем в главных новостях. :)
| |
1.97, cryo (ok), 13:06, 29/11/2010 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
MacOS 10.6.5 Snow Leopard
Ядро Darwin 10.5.0 Darwin Kernel Version 10.5.0: Fri Nov 5 23:20:39 PDT 2010; root:xnu-1504.9.17~1/RELEASE_I386 i386 i386
Запустил эксплойт.
Система по ощущениям _вообще_ не заметила этого DoS. Все бегает, GUI летает, топ работает :)
Пишу этот пост.
Простой kill -15 из-под юзера убил программу моментально.
Строка из топа:
7669 a.out 97.9 01:50.11 1/1 0 14 22 104K 240K 320K 9640K 2370M 7669 7592 running 501 175 36 85 42 52992338+ 64
Нет времени смотреть, как тут реализовано закрытие сокета. Кому интересно - гляньте.
| |
|
2.98, fidaj (ok), 13:16, 29/11/2010 [^] [^^] [^^^] [ответить]
| +/– |
ну теперь кто бы еще и с виндовс машин дал такую же информацию - тогда бы была более полная картина мира :)
А с мак осью - забавно...
| |
|
1.99, pavlinux (ok), 23:55, 30/11/2010 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Свежий патчиг. Для версии 2.6.37-rc4, но думаю руками сами переделаете.
diff --git a/net/unix/garbage.c b/net/unix/garbage.c
index c8df6fd..f89f83b 100644
--- a/net/unix/garbage.c
+++ b/net/unix/garbage.c
@@ -96,7 +96,7 @@ static DECLARE_WAIT_QUEUE_HEAD(unix_gc_wait);
unsigned int unix_tot_inflight;
-static struct sock *unix_get_socket(struct file *filp)
+struct sock *unix_get_socket(struct file *filp)
{
struct sock *u_sock = NULL;
struct inode *inode = filp->f_path.dentry->d_inode;
@@ -259,9 +259,16 @@ static void inc_inflight_move_tail(struct unix_sock *u)
}
static bool gc_in_progress = false;
+#define UNIX_INFLIGHT_TRIGGER_GC 16000
void wait_for_unix_gc(void)
{
+ /*
+ * If number of inflight sockets is insane,
+ * force a garbage collect right now.
+ */
+ if (unix_tot_inflight > UNIX_INFLIGHT_TRIGGER_GC && !gc_in_progress)
+ unix_gc();
wait_event(unix_gc_wait, gc_in_progress == false);
}
| |
|