system programming
Под катом представлена сводная таблица по играм, представленным на презентации Sony PlayStation 5 — The Future Of Gaming. Таблица пытается ответить на вопросы:
Под катом представлен перевод статьи "Understanding Hardware-enforced Stack Protection".
Авторы: Kernel protection team — Jin Lin, Jason Lin, Niraj Majmudar, Greg Colombo
Это первая (обзорная) публикация задуманной серии из двух переводов о внедрении Intel'овской Control-flow Enforcement Technology (CET) в Windows 10.
В этой публикации представлен перевод вступительной части документа (whitepaper) о новом расширении Armv8.5-A: Memory Tagging Extension (MTE) от компании ARM. MTE стремится повысить безопасность кода, написанного на небезопасных языках, не требуя изменения исходного кода, а в некоторых случаях, и не требуя перекомпиляции. Простое развертывание механизмов обнаружения и предотвращения последствий нарушений безопасности памяти могут предотвратить эксплуатацию большого класса уязвимостей.
В одной из предыдущих публикаций я обещал, после того как получу свой экземпляр, поделиться впечатлениями от использования ноутбука Pinebook Pro. В этой статье я постараюсь не повторяться, поэтому если нужно освежить память об основных технических характеристиках устройства, то предлагаю сначала прочесть предыдущий пост об этом устройстве.
Иногда создается впечатление, что Chromebook'и в основном покупают для того, что бы поставить на них Linux. Навскидку статьи на хабре: одная, вторая, третья, четвертая, ...
Поэтому компания PINE Microsystems Inc. и сообщество PINE64 решили, что рынку помимо Chromebook-полуфабрикатов не хватает Pinebook Pro, который сразу создан в расчете на использование Linux/*BSD в качестве операционной системы.
Под катом представлен перевод презентации "The Windows Notification Facility: The Most Undocumented Kernel Attack Surface Yet", представленной Alex Ionescu и Gabrielle Viala на конференции BlackHat 2018.
Под катом расположен перевод опубликованного FAQ'а о деталях будущей WSL второй версии (автор — Craig Loewen).
В MSDN'овской статье Process Security and Access Rights есть интересная ремарка:
… if process A has a handle to process B with PROCESS_DUP_HANDLE access, it can duplicate the pseudo handle for process B. This creates a handle that has maximum access to process B.
Если вольно перевести это на русский, то тут говорится, что имея описатель на процесс с правом доступа PROCESS_DUP_HANDLE мы можем, используя функцию DuplicateHandle(...), получить описатель с максимально разрешенными масками доступа на этот процесс.
В этой публикации речь пойдет о синтетических модулях и символах отладочного движка Windows (debugger engine). То есть о сущностях, которые можно искусственно добавить в отладчик для раскраски адресов памяти.
В Windows стек растет от больших адресов к меньшим. Иногда это определяется архитектурно, а иногда это просто принятое соглашение. Значение указателя стека (регистр процессора), является указателем на значение в верхней части стека. А значения, расположенные глубже по стеку, соответственно, находятся по большим адресам. Но что происходит с данными, которые расположены по адресам, меньшим, чем указатель стека?
Соглашения для некоторых (но не для всех) архитектур определяют красную зону, которая является областью памяти под указателем стека, но которая по-прежнему валидна для использования приложением.
В августе 2016 года, без каких-либо официальных объявлений со стороны Google, были обнаружены исходники новой операционной системы 
Fuchsia. Эта ОС основана на микроядре под названием Zircon, которое в свою очередь основано на LK (Little Kernel).
Fuchsia is not Linux
Я не настоящий сварщик являюсь разработчиком и/или экспертом Zircon. Текст под катом является компиляцией частичных переводов: официальной документации Zircon vDSO и статьи Admiring the Zircon Part 1: Understanding Minimal Process Creation от @depletionmode, куда было добавлено немного отсебятины (которая убрана под спойлеры). Поэтому конструктивные предложения по улучшению статьи, как и всегда, приветствуются.
vDSO в Zircon является единственным средством доступа к системным вызовам (syscalls).
А разве нельзя из нашего кода напрямую вызвать инструкции процессора SYSENTER/SYSCALL? Нет, эти инструкции процессора не являются частью системного ABI. Пользовательскому коду запрещено напрямую выполнять такие инструкции.
Желающих узнать больше деталей о таком архитектурном шаге приглашаю под кат.
Под катом расположен перевод вступительной части документа Detecting Kernel Memory Disclosure with x86 Emulation and Taint Tracking (Статья Project Zero) от Mateusz Jurczyk.
В переведенной части документа:
Хотя в документе пристально рассматриваются механизмы общения привилегированного ядра ОС с пользовательскими приложениями, суть проблемы можно обощить для любой передачи данных между различными доменами безопасности: гипервизор — гостевая машина, привилегированный системный сервис (демон) — GUI приложение, сетевые клиент — сервер и т.д.
По роду своей деятельности (Windows Kernel) мне регулярно приходится разбирать дампы BSOD'ов. Не единичны случаи, когда у конечного пользователя успешно пишутся только Mini-дампы, в которых сохраняется только значение регистров процессора и стек падения. А другого средства отладки клиентской машины просто нет. Но что делать, если в стеке нет нашего драйвера, а заказчик настаивает, что падения начались после установки продукта и закончились после отключения драйвера этого продукта? В моем случае хорошим решением оказалось ведение небольшого журнала последних событий в циклическом буфере. Осталось только сохранить этот циклический буфер в дампе.
Под катом я расскажу, как из своего драйвера добавить в дамп данные. А затем извлечь их, используя pykd.
