1.1, anonymous (??), 13:47, 02/08/2011 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
А разве нельзя установить квоты на максимальный размер выделяемой памяти для sshd?
| |
|
2.2, codejumper (?), 13:56, 02/08/2011 [^] [^^] [^^^] [ответить]
| +/– |
если ограничивать на каждый процесс, то их можно ещё кучу наплодить
если по сумме, то легальные пользователи не смогут заходить, т.ч. также получаем dos
| |
|
3.4, Аноним (-), 16:48, 02/08/2011 [^] [^^] [^^^] [ответить]
| +/– |
Вообще-то достаточно ограничить пользователя и всё. Если уязвимость требует наличия аккаунта, значит sshd уже сделал setuid и работает из-под пользователя - итого никакой опасности и в логах сразу будет видно кто шалит.
| |
|
|
1.3, Аноним (-), 16:45, 02/08/2011 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Большими malloc'ами нельзя исчерпать свободную память в системе, потому что при malloc'е физические страницы не выделяются - делается банальный анонимный mmap. Либо переводчик лажанул и там было что-нибудь про заполнение этой памяти, либо это уязвимость - чушь на постном масле, либо работает только на редких системах с ущербной виртуальной памятью.
| |
|
2.5, Аноним (-), 17:38, 02/08/2011 [^] [^^] [^^^] [ответить]
| +/– |
> Большими malloc'ами нельзя исчерпать свободную память в системе, потому что при malloc'е
> физические страницы не выделяются - делается банальный анонимный mmap.
Вы бы вначале на код посмотрели, прежде чем критиковать. OpenSSH сразу забивает содержимое буфера перед использованием, что и приводит к физическому выделению страниц:
name->value = xmalloc(name->length+1);
memcpy(name->value, tok+offset, name->length);
| |
|
3.6, pro100master (ok), 18:49, 02/08/2011 [^] [^^] [^^^] [ответить]
| +/– |
рискую быть неправым, но разве в современных менеджерах не copy-on-write схема? Где копирование физически происходит только при изменении исходных данных? Память она такая - сейчас самая дорогая операция, глупо писать бит при пенальти в 50-200 тактов.
| |
|
4.8, Аноним (-), 19:13, 02/08/2011 [^] [^^] [^^^] [ответить]
| +/– |
> рискую быть неправым, но разве в современных менеджерах не copy-on-write схема?
При чём тут cow? Если вы думаете что процессор через libastral определяет что содержимое страниц идентично и шарит страницы вместо копирования, то это бред.
| |
|
5.9, pro100master (ok), 19:17, 02/08/2011 [^] [^^] [^^^] [ответить]
| +/– |
Ни процессор, ни процесс тут совершенно не причем. Это забота MM. Он как раз всё про всех знает. Причем, он еще и тем самым астралом планирует выделения/освобождения на основе своей статистики.
| |
|
6.10, Аноним (-), 19:20, 02/08/2011 [^] [^^] [^^^] [ответить]
| +/– |
> Ни процессор, ни процесс тут совершенно не причем. Это забота MM. Он как раз всё про всех знает. Причем, он еще и тем самым астралом планирует выделения/освобождения на основе своей статистики
Лол.
| |
|
|
8.12, Аноним (-), 21:22, 02/08/2011 [^] [^^] [^^^] [ответить] | +/– | Вполне доступна, если захотите разберётесь Начните с осознания того, что менедж... текст свёрнут, показать | |
|
|
|
|
4.16, Andrew Kolchoogin (?), 10:22, 03/08/2011 [^] [^^] [^^^] [ответить]
| +/– |
Нет. Аллокатор всегда выделяет страницы сразу.
Функция malloc() возвращает либо указатель на область ОЗУ, либо NULL, если выделение ОЗУ по каким-либо причинам не удалось. Если выделять ОЗУ фиктивно, тогда от момента вызова malloc() до момента записи в выделенную область ОЗУ вполне может выполниться несколько malloc()'ов других процессов (напоминаю: UNIX -- система многозадачная), и когда фиктивное выделение придётся сделать физическим, ОЗУ может просто закончиться.
Что тогда? SIGKILL "Out of swap space"? Это неправильно. Противоречит семантике работы malloc(). Если ОЗУ нет -- возвратите NULL и не полируйте моск. Если возвратили указатель -- отдайте моё ОЗУ мне.
| |
|
5.17, Михаил (??), 11:26, 03/08/2011 [^] [^^] [^^^] [ответить]
| +/– |
>Если ОЗУ нет - возвратите NULL и не полируйте моск. Если возвратили указатель - отдайте моё ОЗУ мне.
echo "vm.overcommit_memory = 2" >> /etc/sysctl.conf
| |
|
6.23, Andrew Kolchoogin (?), 23:48, 03/08/2011 [^] [^^] [^^^] [ответить]
| –1 +/– |
Тщательный анализ grep'ом по исходникам ядра показал, что слово 'overcommit' встречается в vm/swap_pager.c, но отвечает только за возможность выделения ФИЗИЧЕСКОГО ОЗУ для процесса в количестве, большем, чем есть СВОБОДНОГО СВОПА.
Такая ситуация возможна, если в системе размер ОЗУ больше размера свопа, но для FreeBSD такие настройки нехарактерны -- Handbook рекомендует иметь свопа больше, чем физического ОЗУ.
Впрочем, доки на Солярис говорят, что лучше наоборот, но там и sysctl такого нет. :)
| |
|
5.20, Аноним (-), 21:47, 03/08/2011 [^] [^^] [^^^] [ответить]
| +1 +/– |
> Нет. Аллокатор всегда выделяет страницы сразу.
Вы уже не раз показали себя ламером, может пора научиться хотя-бы проверять, прежде чем говорить о том, о чём понятия не имеете? Сделайте программу, malloc(); system("ps"); memset(); system("ps"); и посмотрите что будет с VM и RSS.
> Что тогда? SIGKILL "Out of swap space"?
Именно, и это правильно.
> Противоречит семантике работы malloc()
OOM killer не имеет никакого отношения к семантике работы malloc, и избежать его всё равно нельзя из-за фундаментальных принципов работы системы виртуальной памяти. Кроме того, выделение физических страниц на аллокации - это кошмарное падение производительности, рост потребления памяти, невозможность выделить фрагмент больше размера физической памяти.
Почему нельзя избежать OOM - показываю на примере: процесс выделил много памяти, допустим даже честно выделил физические страницы, далее он форкается. Либо вы честно копируете всё адресное пространство (а с такой системой вы никому не нужны), либо одна из копий будет убита при записи в память, когда при cow кончатся физические страницы.
Другой пример - процесс выделил память-ok, был вытеснен в swap и весь его занял. Другой процесс выделил память-ok, и занял всё физическую. Когда проснётся первый процесс и полезет из swap'а, он будет прибит безо всяких malloc по причине исчерпания физических страниц.
Итого - на деле malloc вернёт 0 скорее всего только в одном случае - при исчерпании адресного пространства (т.е. невозможности сделать анонимный mmap). Во всех остальных случаях процесс будет убит по OOM, это полностью ожидаемое и корректное поведение.
| |
|
6.22, Andrew Kolchoogin (?), 23:19, 03/08/2011 [^] [^^] [^^^] [ответить]
| +/– |
> Итого - на деле malloc вернёт 0 скорее всего только в одном
> случае - при исчерпании адресного пространства (т.е. невозможности сделать анонимный mmap).
> Во всех остальных случаях процесс будет убит по OOM, это полностью
> ожидаемое и корректное поведение.
По уточнённым данным:
===
{40} user@host:/usr/src/lib/libc $ cc -I /usr/src/lib/libc/include -E stdlib/malloc.c | grep -v "^#" | grep '= mmap'|wc -l
1
{41} user@host:/usr/src/lib/libc $ cc -I /usr/src/lib/libc/include -E stdlib/malloc.c | grep -v "^#" | grep 'return (0)' | wc -l
16
===
Итого, случаев возврата NULL'ей в malloc() ровно в 16 раз больше случаев вызова mmap().
| |
|
|
|
3.7, Аноним (-), 19:11, 02/08/2011 [^] [^^] [^^^] [ответить]
| +/– |
> Вы бы вначале на код посмотрели
Я, по-моему, всё ясно написал:
> Либо переводчик лажанул и там было что-нибудь про заполнение этой памяти | |
|
|
|