Хотя в современных Linux-системах ядро отличается достаточно высоким уровнем стабильности, вероятность серьезных системных ошибок, тем не менее, имеется всегда. Когда происходит неисправимая ошибка, имеет место состояние, называемое паникой ядра (kernel panic): стандартный обработчик выводит на экран информацию, которая должна помочь в устранении неисправности, и входит в бесконечный цикл.
Читать полностью »
Лето началось жарко. Совсем недавно мы пофиксили CVE-2014-0196, позволяющую получить локального рута, как на подходе еще одна подобная локальная уязвимость: CVE-2014-3153. И хоть рабочего эксплойта публично пока что нет, затронуты все актуальные версии ядер: от 2.6.32 и до 3.14.5.
Примечание для гентушников: в отличие от CVE-2014-0196 hardened-ядра тоже затронуты.
Привожу перевод исходного информационного письма из списка рассылки:
Pinkie Pie (я так понял, это какой-то сильный исследователь безопасности скрывается под ником персонажа из My Little Pony — примечание переводчика) обнаружил проблему в подсистеме futex, которая позволяет локальному пользователю получить контроль над ring 0 через системный вызов futex. Непривелигированный пользователь может использовать эту уязвимость для краха ядра (приводящему к отказу в обслуживании (DoS)) или повышению привилегий.
Волею судеб мне довелось разбираться с организацией многозадачности, точнее псевдо-многозадачности, поскольку задачи делят время на одном ядре процессора. Я уже несколько раз встречала на хабре статьи по данной теме, и мне показалось, что данная тема сообществу интересна, поэтому я позволю себе внести свою скромную лепту в освещение данного вопроса.
Сначала я попытаюсь рассказать о типах многозадачности (кооперативной и вытесняющей). Затем перейду к принципам планирования для вытесняющей многозадачности. Рассказ рассчитан скорее на начинающего читателя, который хочет разобраться, как работает многозадачность на уровне ядра ОС. Но поскольку все будет сопровождаться примерами, которые можно скомпилировать, запустить, и с которыми при желании можно поиграться, то, возможно, статья заинтересует и тех, кто уже знаком с теорией, но никогда не пробовал планировщик “на вкус”. Кому лень читать, может сразу перейти к изучению кода, поскольку код примеров будет взят из нашего проекта.
Ну, и многопоточные котики для привлечения внимания.
Есть у меня несколько VPS'ок с Gentoo, бегущих под VMWare, для которых я, пожадничав, выделил всего по 7G дискового пространства. Как-то раз, после выхода очередной версии gcc, на одной из них закончилось место. Покопавшись, я обнаружил, что главными потребителями были директории /usr/src и /usr/portage. Тут же родилась мысль переместить их на файловую систему с компрессией (ага, на NTFS) и выбор пал на Reiser4, так как эти данные идеально подходят для неё — очень много файлов и они все маленькие.
Про эту файловую систему в сети имеется множество противоречивой информации (2013), но, пожалуй, стоит почитать статью (2010) ведущего разработчика. Цитата из статьи:
за последние четыре года я не помню, чтобы кто-то терял данные на reiser4 разделе при исправно работающем железе. Ко мне обращалось несколько человек с жалобой на работу fsck. В конечном итоге все они получали и свои данные и работающий fsck.
Не надо её бояться…
Читать полностью »
Перехват функций ядра является базовым методом, позволяющим переопределять (дополнять) различные его механизмы. Исходя из того, что за исключением небольших архитектурно-зависимых частей, ядро Linux почти полностью написано на языке C, можно утверждать, что для осуществления встраивания в большинство из компонентов ядра, достаточно иметь возможность перехвата соответствующих функций ЯВУ, реализующих ту или иную логику.
Данная статья является практическим обобщением представленных ранее статей:
Далее будет рассмотрено каким образом использование данных материалов может быть применимо в обеспечении возможности перехвата функций ядра Linux.
Читать полностью »
Сегодня на SecurityLab в «TOP Новостях» появилась ссылка на «Множественные уязвимости KVM».
Интересно посмотреть, думаю, я же копаюсь в нём сейчас. Тем более — open source: можно сразу и на патч посмотреть.
Всем, кому интересно, как инженер по безопасности ПО из Google и главный инженер-программист из Red Hat закоммитили в kernel/git/torvalds/linux.git ненужный патч несуществующей уязвимости, добро пожаловать под кат.
Те, кто хоть однажды сталкивался с необходимостью поменять что-то в ядре на лету не понаслышке знают, что данный вопрос требует детальной проработки, ведь страницы памяти ядра, хранящие код и некоторые данные, помечены как «read-only» и защищены от записи!
Для x86 известным решением является временное отключение страничной защиты посредством сброса бита WP регистра CR0. Но следует применять это с осторожностью, ведь страничная защита является основой для многих механизмов ядра. Кроме того, необходимо учитывать особенности работы на SMP-системах, когда возможно возникновение разных неприятных ситуаций.
Обработка исключений занимает важное место в процессе функционирования программных систем. Действительно, обеспечение своевременной и правильной реакции на нештатные события является одной из ключевых задач, выполняемых операционной системой и, в особенности, её ядром. Будучи современным, ядро Linux предоставляет возможность управления процессом обработки исключений, однако ввиду ограниченности его интерфейса, данный механизм не является распространённым среди разработчиков модулей ядра.
Далее, на примере PageFault будут рассмотрены некоторые особенности процесса обработки исключений, а также дано описание метода, позволяющего использовать данную возможность при разработке модулей ядра Linux для архитектуры x86.
Зачесалось — написалось.
Проверено на Lightmark2008 и Unigine Heaven 2.5 и 4.0.
Конфиг: AMD64, Linux 3.12.0-rc2+, Geforce GTS250.
Я Draw
В начале было «Я»
Привет!
Я часто исследую разные задачи, проблемы и вот одна из них — оказалось, что есть много много GNU дистрибутивов, но все они так или иначе работают по принципам unix, то есть как такового развития не происходит, развиваются программы, ядро, а вот структура как была x-летней давности так и осталась, в общем-то это объясняется проблемами совместимости, которые могут возникнуть в случае попытки прыжка на месте. Я решил задуматься о том какие могут быть возможности развития GNU/Linux и в то же время о вариантах объединения сообществ разных дистрибутивов, поэтому подозреваю, что есть адепты в том числе и оконных поделок, и бсделок, а для меня и не-иксы примерно все одинаковые, по крайней мере в плане распределения транзакций между кэшэмкэшами ядер процессоров, предлагаю сразу же git дружно.
Задача этого поста — привлечь внимание аудитории к проблеме, оценить степень её важности и попробовать найти более совершенное исполняемое решение, хотелось бы добрых намерений и возможной добровольной помощи в реализации.
Читать полностью »
