https://opennet.ru/openforum/vsluhforumID3/80467.html Под конец только что завершившегося хакатона (http://www.openbsd.org/hackathons.html) s2k11 в Словении, в базовую систему импортирован (http://marc.info/?l=openbsd-cvs&m=131673440721777&w=2) http-сервер nginx (http://www.nginx.ru/), развиваемый Игорем Сысоевым (http://www.sysoev.ru/). В ближайшем будущем планируется, что nginx займёт место Apache 1.3 в базовой системе OpenBSD. На данный момент nginx не включён в сборку, так как требуется решить ещё несколько технических вопросов, таких как использование встроенной PCRE-библиотеки, совмещение chroot, лог-файлов и обновления конфигурации.<br><br><br>Это далеко не единственное, что происходит в рамках разработки OpenBSD:<br><br><br>- Полным ходом идут работы над полноценной загрузкой с softraid(4) (http://www.openbsd.org/cgi-bin/man.cgi?query=softraid&sektion=4&manpath=OpenBSD+Current&format=html): корневой раздел в -CURRENT уже можно использовать прямо с softraid без ухищрений, но ядро пока что должно грузиться с отдельного диска;<br><br>- Готовится подд...<br><br>URL: <br>Новость: http https://opennet.ru/openforum/vsluhforumID3/80467.html#147 Sun, 09 Oct 2011 17:05:49 GMT &gt; Сборка как бы всегда нагружала в первую очередь процессор. ;)<br><br>Смотря какая, сишное барахлишко уже довольно давно летит струёй, не загружая ядра полностью, если не поддать -j до N+1..2. Плюсовое -- да, наваливается на CPU.<br><br>&gt; А в случае tmpfs говорить про ввод-вывод вообще не особо уместно. ;)<br><br>Этот случай был упомянут "хозяйке на заметку" :)<br><br>&gt; И главное, причём тут самоуспокоение, если сборка как раз идёт не в ядре? :)<br><br>А I/O где идёт?<br><br>&gt;&gt; и то 500Mb/s sustained write было не в диковинку [...]<br>&gt; МегаБАЙТ или мегаБИТ? ;) <br><br>Байт, конечно (иначе бы написал Mbps, хотя согласен, лучше уточнить сразу).<br><br>&gt; AFAIK, поток от одного контроллера не параллелится, прерывание-то одно.<br><br>Ну так их и несколько ставят порой... в стораджевых драйверах я даже не чайник, что там с/от SMP, не знаю -- могу техдира спросить при случае.<br><br>&gt; И главное - куда этот поток пойдёт?<br><br>Скорее уж не "куда пойдёт", а "какой поток упрётся в одно доступное ядро".<br><br>&gt; Эм, а чем это SAS не SCSI? :) <br><br>Разъёмчиком не вышел. :)<br> https://opennet.ru/openforum/vsluhforumID3/80467.html#146 Sat, 08 Oct 2011 15:30:44 GMT &gt;&gt; Я говорил про собственно ввод-вывод. Который, на минуточку, практически всегда <br>&gt;&gt; медленнее, чем его может жевать процессор.<br>&gt; Это на сейчас неверный подход и самоуспокоение. Конкретно у меня на <br>&gt; сборочном ноуте сейчас основной упор именно в процессор -- поскольку сборка <br>&gt; в tmpfs и SSD.<br><br>Сборка как бы всегда нагружала в первую очередь процессор. ;) А в случае tmpfs говорить про ввод-вывод вообще не особо уместно. ;) И главное, причём тут самоуспокоение, если сборка как раз идёт не в ядре? :)<br><br>&gt; Причём вычислительная мощность одного процессорного ядра скорее остановилась, а I/O призадумалось <br>&gt; только на HDD, и то 500Mb/s sustained write было не в <br>&gt; диковинку на железе дешевле $3000 опять же лет пять тому (помнится, <br>&gt; HP DL385 с P400i и 6/8? 2.5" SAS HDD).<br><br>МегаБАЙТ или мегаБИТ? ;)<br><br>&gt;&gt; Или ваши жёсткие диски (вместе с контроллерами) научились отдавать (я молчу про запись) <br>&gt;&gt; эдак гигабайт в секунду?<br>&gt; Это они у нас и пять лет тому умели, если уже не <br>&gt; больше (одна 16-портовая Areca https://opennet.ru/openforum/vsluhforumID3/80467.html#145 Sat, 08 Oct 2011 08:50:26 GMT &gt; Я говорил про собственно ввод-вывод. Который, на минуточку, практически всегда<br>&gt; медленнее, чем его может жевать процессор.<br><br>Это на сейчас неверный подход и самоуспокоение. Конкретно у меня на сборочном ноуте сейчас основной упор именно в процессор -- поскольку сборка в tmpfs и SSD.<br><br>Причём вычислительная мощность одного процессорного ядра скорее остановилась, а I/O призадумалось только на HDD, и то 500Mb/s sustained write было не в диковинку на железе дешевле $3000 опять же лет пять тому (помнится, HP DL385 с P400i и 6/8? 2.5" SAS HDD).<br><br>&gt; Или ваши жёсткие диски (вместе с контроллерами) научились отдавать (я молчу про запись)<br>&gt; эдак гигабайт в секунду?<br><br>Это они у нас и пять лет тому умели, если уже не больше (одна 16-портовая Areca затыкалась, но две восьмипортовки в тупом режиме более-менее справлялись). Сейчас же при необходимости организовать такой поток цена вопроса -- меньше килобакса.<br><br>&gt; Не, конечно, можно при желании достаточно современный SCSI-контроллер засунуть <br>&gt; в машину с процом п https://opennet.ru/openforum/vsluhforumID3/80467.html#144 Sat, 08 Oct 2011 00:36:57 GMT &gt;[оверквотинг удален]<br>&gt; [...] <br>&gt;&gt; Если не будет параллельной работы userland-кода, то весь супер-пупер-быстрый ввод-вывод <br>&gt;&gt; будет всё равно упираться в не успевающую его прожёвывать программу.<br>&gt; Ввод-вывод не может ни во что упереться, а программа ничего не должна <br>&gt; успевать за ядром. Вы путаете причинно-следственную связь: программа через сисколы просит <br>&gt; ядро сделать вон то и вон это. А ядро идет и <br>&gt; делает. Ядро не может сделать больше чем его попросили. Оно может <br>&gt; протормозить с выполнением сискола, но больше чем программе надо - оно <br>&gt; в принципе запихнуть в нее не может. Потому что это программа <br>&gt; инициирует запрос, а ядро его разруливает.<br><br>И-и-и?..<br><br>&gt;&gt; Единственное исключение - ситуации, когда ввод-вывод полностью или <br>&gt;&gt; практически полностью обрабатывается ядром: та же маршрутизация сетевых <br>&gt;&gt; пакетов, например (т.е. сквозь машину, а не к ней или от неё).<br>&gt; Что значит - единственное исключение? Юзерланд, особенно способный к работе на нескольких <br>&gt; процессорах - на раз упр https://opennet.ru/openforum/vsluhforumID3/80467.html#143 Sun, 02 Oct 2011 12:36:45 GMT &gt;&gt; Потому что одно не отменяет другого. Если у вас (хакера) есть два <br>&gt;&gt; врага, Вася (ядро) и Петя (обычный процесс), и на Пете есть <br>&gt;&gt; бронежилет, которого нет на Васе, это ещё не 100% гарантия, что <br>&gt;&gt; Вася сдастся раньше Пети. Здесь можно вести речь лишь о вероятностях.<br>&gt; Ну, как показала практика, Петя таки сдался раньше Васи. В OpenSSH опубликовали <br><br>Имена перепутал. Вася, который ядро, сдался раньше.<br> https://opennet.ru/openforum/vsluhforumID3/80467.html#142 Sun, 02 Oct 2011 08:20:41 GMT &gt; Не совсем понял фразы "общий стек": для каждого потока выполнения в ядре <br>&gt; свой стек. Но добраться до этого стека при условии, что мы <br><br>Имелся ввиду общий стек системных вызовов.<br><br>&gt; Другое дело, что возможность считать произвольный адрес в памяти несёт в себе <br>&gt; столько потенциальных угроз (вроде считывания ключей IPSec), что в гроб ложиться <br>&gt; можно сразу. Так что я бы не стал заморачиваться утаиванием канарейки,<br><br>"Чтение произвольного адреса" бывает разным - это может быть и off-by-one, и частично подконтрольное атакующему значение смещения относительно указателя, и целочисленное переполнение не более, чем на некоторую величину. Уязвимостей к абсолютно случайному чтению существует гораздо меньше, чем к ограниченному.<br> <br>&gt; а обратил внимание в первую очередь на исходную проблему (возможности считывания), <br>&gt; как более актульную. Тем более, что никакой дополнительный слой защиты от <br>&gt; таких ошибок не спасёт: как он отличит легальное обращение к, скажем, <br>&gt; контексту процесса от нелегального?<br><br>В https://opennet.ru/openforum/vsluhforumID3/80467.html#141 Sun, 02 Oct 2011 03:53:50 GMT [...]<br>&gt;&gt; вычислительных задач (CPU-bound нежели I/O bound). Ну да, крякеры мд5 на <br>&gt;&gt; скорость тормзить не будут. А вот I/O bound программы (столь типичные <br>&gt;&gt; для серверов) будут часто стоять колом<br><br>[...]<br>&gt; Если не будет параллельной работы userland-кода, то весь супер-пупер-быстрый ввод-вывод <br>&gt; будет всё равно упираться в не успевающую его прожёвывать программу. <br><br>Ввод-вывод не может ни во что упереться, а программа ничего не должна успевать за ядром. Вы путаете причинно-следственную связь: программа через сисколы просит ядро сделать вон то и вон это. А ядро идет и делает. Ядро не может сделать больше чем его попросили. Оно может протормозить с выполнением сискола, но больше чем программе надо - оно в принципе запихнуть в нее не может. Потому что это программа инициирует запрос, а ядро его разруливает.<br><br>&gt; Единственное исключение - ситуации, когда ввод-вывод полностью или<br>&gt; практически полностью обрабатывается ядром: та же маршрутизация сетевых<br>&gt; пакетов, например (т.е. сквозь машину, а не к ней https://opennet.ru/openforum/vsluhforumID3/80467.html#140 Sun, 02 Oct 2011 03:14:34 GMT &gt; вызовов в случае ядра). Впрочем, для её считывания всё равно надо <br>&gt; иметь возможность читать более-менее произвольную область памяти. (см. ниже) <br><br>Для её считывания достаточно утечки неинициализированной переменной или неинициализированной области выравнивания полей структуры.<br><br>Вы не знаете об этом или не рассматриваете по каким-то другим причинам?<br> https://opennet.ru/openforum/vsluhforumID3/80467.html#139 Fri, 30 Sep 2011 17:24:14 GMT &gt;&gt; будет известно. Хреново.<br><br>Можете мя закапывать - я сослепу перепутал в листинге запись константы и обращение к памяти по заданному адресу... После дополнительных проверок - таки да, канарейка выставляется случайная при запуске, общая для всех функций (системных вызовов в случае ядра). Впрочем, для её считывания всё равно надо иметь возможность читать более-менее произвольную область памяти. (см. ниже)<br><br>&gt;&gt; Если не стоковое, то нужна не просто утечка, <br>&gt;&gt; а из данного системного вызова. Две разных уязвимости на один системный <br>&gt; Уязвимость к утечке может быть где угодно. Главное, чтобы утечка произошла с <br>&gt; адреса на общем стеке, где лежит canary-значение, сохранившееся после предыдущего сисколла. <br><br>Не совсем понял фразы "общий стек": для каждого потока выполнения в ядре свой стек. Но добраться до этого стека при условии, что мы можем считывать произвольную область памяти через уязвимость в произвольном системном вызове, конечно, можно.<br><br>Другое дело, что возможность считать произвольный адрес в памя