LINUX.ORG.RU

Выявлена дыра, позволяющая «уронить» компьютер с Linux под любым пользователем

 ,


0

2

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

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

>>> Подробности

★★★★★

Проверено: post-factum ()
Последнее исправление: post-factum (всего исправлений: 2)
Ответ на: комментарий от sv75

>А, у нас еще и буфер нужен «на сто(тысячу) килобайт пакетов TCP SYN»?

ну и данные ещё кстати тогда копируются *много* раз.


Этот буфер будет областью shared memory, к которой нужные процессы будут иметь доступ только на чтение, а нужные - на чтение и запись.

Объём данных, подвергающихся копированию, равен и в случае монолитного ядра и в случае микроядра с процессами. Поэтому и в случае с монолитным ядром данные тоже копируются *много* раз.

morbo
()
Ответ на: комментарий от morbo

> Этот буфер будет областью shared memory, к которой нужные процессы будут иметь доступ только на чтение, а нужные - на чтение и запись.

Ну только это не микро ядро вроде бы будет, там предполагались асинхронные сообщения же?

Поэтому и в случае с монолитным ядром данные тоже копируются *много* раз.

В рабочих стека TCP/IP всё копируется теоретически минимальное число раз.

sv75 ★★★★★
()
Ответ на: комментарий от morbo

> Этот буфер будет областью shared memory, к которой нужные процессы будут иметь доступ только на чтение, а нужные - на чтение и запись.

Если во всех драйверах вся память будет shared memory, то зачем было выделять их в отдельные процессы? Пусть бы работали в ядре, там вся память итак shared. :)

Объём данных, подвергающихся копированию, равен и в случае монолитного ядра и в случае микроядра с процессами.

Если бы все было так просто. Объем «полезных» данных у них одинаковый, но память они используют по-разному. Из простых примеров - кеш в линуксе. В линуксе используется логичный подход - вся неиспользуемая программами память отдается под кеш. Действительно, если память все равно есть, зачем ей простаивать. А если какая-то программа просит еще памяти, то самая ненужная часть кеша освобождается. Просто и гениально. В монолитном ядре.

Теперь представим, что у нас микроядро, причем вся память кеша смаплена в shared memory разных процессов файловых систем. Они ее активно используют, читают, пишут, наверное как-то передают указатели друг другу и драйверам, когда надо считать очередной файл, и т.д.

Пока оставим вопрос того, как файловые системы будут общаться с драйверами - это отдельная головная боль. Рассмотрим только вопрос памяти. Новый процесс попросил память. Каким образом система ее выделит? С точки зрения ядра - вся память занята процессами. Как попросить кучу разных процессов освободить память? Причем не просто память, а shared memory? Да и как вообще определить, какие процессы надо просить?

anonymous
()
Ответ на: комментарий от anonymous

>Если во всех драйверах вся память будет shared memory, то зачем было выделять их в отдельные процессы? Пусть бы работали в ядре, там вся память итак shared. :)

Затем, что к этой области shared memory будут иметь доступ только те драйверы, которым она нужна для работы. Сейчас же все драйверы имеют доступ ко всей памяти.

Если бы все было так просто. Объем «полезных» данных у них одинаковый, но память они используют по-разному. Из простых примеров - кеш в линуксе. В линуксе используется логичный подход - вся неиспользуемая программами память отдается под кеш. Действительно, если память все равно есть, зачем ей простаивать. А если какая-то программа просит еще памяти, то самая ненужная часть кеша освобождается. Просто и гениально. В монолитном ядре.


Теперь представим, что у нас микроядро, причем вся память кеша смаплена в shared memory разных процессов файловых систем. Они ее активно используют, читают, пишут, наверное как-то передают указатели друг другу и драйверам, когда надо считать очередной файл, и т.д.


Пока оставим вопрос того, как файловые системы будут общаться с драйверами - это отдельная головная боль. Рассмотрим только вопрос памяти. Новый процесс попросил память. Каким образом система ее выделит? С точки зрения ядра - вся память занята процессами. Как попросить кучу разных процессов освободить память? Причем не просто память, а shared memory? Да и как вообще определить, какие процессы надо просить?


Стоп-стоп-стоп, помедленнее. Когда кому-то понадобится память, у кого она будет отнята в случае монолитного ядра? У системы кэширования. В случае с микроядром нужно будет просить освободить память только систему кэширования. Если кэш уже используется каким-то модулем ядра, то кэш тоже нельзя будет внезапно освободить.

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

Точно так же будет работать и подсистема кэширования в микроядре - она будет постоянно общаться с системой управления памятью, которая находится в ядре.

morbo
()
Ответ на: комментарий от sv75

>Ну только это не микро ядро вроде бы будет, там предполагались асинхронные сообщения же?

Что такое «асинхронные» и что такое «сообщения».

Сообщения - это просто альтернатива блокировкам. Если обработчик сообщения один, то все отправители становятся в очередь ожидания готовности обработчика.

Асинхронность - это возможность сделать запрос и продолжить работу, не дожидаясь выполнения запроса и результатов его выполнения. Она достижима и в случае с сообщениями и в случае с системными вызовами.

Ни сообщения, ни их асинхронность не предполагают, что большой объём данных будет передаваться в теле сообщения. Также как и ни системные вызовы ни асинхронные системные вызовы не предполагают передачу большого объёма данных через стек.

В рабочих стека TCP/IP всё копируется теоретически минимальное число раз.


Слепая вера такая слепая...

morbo
()
Ответ на: комментарий от morbo

> Слепая вера такая слепая...

Я как-то неделю потратил на выяснение этой проблемы. Ставил хуки в ядерном memcpy.

sv75 ★★★★★
()
Ответ на: комментарий от morbo

> Сообщения ... не предполагают, что большой объём данных будет передаваться в теле сообщения.

Ага, ага. Они предполагают shared memory и синхронизацию для доступа ней семафорами, ну конечно же!

В общем, было бы интересно узнать как сделано стек TCP в Миникс. Как узнаете, можете рассказать. А пока у вас пустое теоретизирование без доказательств.

sv75 ★★★★★
()
Ответ на: комментарий от morbo

> Когда кому-то понадобится память, у кого она будет отнята в случае монолитного ядра? У системы кэширования. В случае с микроядром нужно будет просить освободить память только систему кэширования.

В случае монолитного ядра кеш может действительно освободить соответствующий сегмент. А с микроядром и shared memory так не выйдет. Даже если кеш сделает detach соответствующей области памяти - это не освободит ее, до тех пор, пока все драйвера, файловые системы и другие тоже не «закроют» этот сегмент. Получается, нет гарантированного способа освободить такую память.

Потом, кэш - это не обязательно память используемая прямо сейчас каким-то процессом.

Это не важно. Важно только то, что эта память сейчас может быть смаплена в нескольких процессах - в процессе драйвера, который считал ее с диска (ведь кто-то ж ее считал?), в процессе кеша и процессе файловой системы. Или даже нескольких файловых систем. А может и нескольких драйверов, ведь у нас же общий кеш для USB и IDE? Освободить память, которая занята неизвестно кем - вот проблема.

или просто пометит страницы памяти, как не используемые

Кеш - это процесс? Тогда не пометит. В лучшем случае - сделает detach&close и будет надеяться, что больше ни у кого эта память не смаплена.

Точно так же будет работать и подсистема кэширования в микроядре - она будет постоянно общаться с системой управления памятью, которая находится в ядре.

Таак. Мы подходим к интересному месту: менеджер памяти В ЯДРЕ зависит от ПРОЦЕССА кеширования. Падает кеш - падает и ядро? Или дисковый кеш - тоже часть ядра (не путать с paging-ом, до него мы еше доберемся)?

anonymous
()
Ответ на: комментарий от sv75

> Я как-то неделю потратил на выяснение этой проблемы. Ставил хуки в ядерном memcpy.

Какой проблемы, если не секрет? Мне интересны вопросы производительности сетевых вызовов.

PS: а ядерный memmove проверялся? ;)

anonymous
()
Ответ на: комментарий от anonymous

Сколько раз копируются данные при работе TCP.

sv75 ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.