The Kernel-Bridge Framework: мостик в Ring0

[dreamer-dead]

А что из С++17 реально используется?
С первого взгляда, там и С++11 могло бы хватить, но я пару файлов всего глянул.

[aleksanderem]

Мелочи, типа [[fallthrough]]. В ядерном коде с нововведениями не разойтись, но выставил сразу поддержку последнего черновика C++ (формально, уже C++20), чтобы при попытке обновить стандарт не возникло неприятных неожиданностей и варнингов. 99%, конечно же, C++11.

[dreamer-dead]

Так оно того стоило? Далеко не все горят желанием и возможностью обновлять тулчейн по желанию. Может, стоило макросом закрыть для «бедных»?
Что кстати с клангом для сборки драйверов, не знаете? Там по моему с SEH у них нестыковки по прежнему.

[aleksanderem]

Я сторонник использования новейшего стека технологий, и использование устаревшего стандарта было бы ударом по моим перфекционистическим чувствам) А вообще, коль скоро драйвера в подавляющем количестве пишут на C без плюсов, уже сам факт использования C++ в API может добавить неудобств тем, кто захочет перенести часть функций в уже существующий продукт. А если писать с нуля — тогда и смысла нет привязываться к старым стандартам, когда ничто не мешает сразу использовать всё самое новое.

Про клэнг ничего не могу сказать — не пробовал. Но, судя по постам на unknowncheats, им успешно собирают драйвера с поддержкой STL из коробки. А как разруливают исключения — не знаю. Но, раз клэнг используют в ядре, с сехами проблем быть не должно. С другой стороны, какие есть причины собирать им ядерные модули и не лучше ли использовать официальный тулчейн?

[atrosinenko]

Я правильно понимаю, что это предназначено исключительно для прототипирования и ни в коем случае нельзя оставлять на production?

[aleksanderem]

Зависит от используемого функционала. Например, функции для работы с IO, MSR, чтение\запись памяти (в т.ч. ядерной) совершенно безопасны для продакшна и сделаны со всеми необходимыми проверками и ловушками исключительных ситуаций (например, с учётом, что приложение может попытаться освободить память или поменять её права доступа, пока мы с ней работаем). Но функции для, скажем, прямых манипуляций с Mdl небезопасны по самой своей сути: если приложение создало отображение и по каким-то причинам закрылось, не сделав анмаппинг — гарантированно получим BSOD при попытке отдать системе смапленные адреса. Такие функции я бы не рекомендовал использовать в юзермодном коде в реальных продуктах. Нужно смотреть, что именно требуется сделать и какие вообще пути для решения есть.

Что касается ядерной части, вполне можно использовать драйвер или API как готовый шаблон для написания своих ядерных компонентов в продакшн.

Если интересует надёжность каких-то конкретных частей драйвера — спрашивайте, обсудим.

[atrosinenko]

Честно говоря, вопрос был, скорее, риторический. :) Просто при первом взгляде напомнило описываемое в статье Драйвер компьютерной игры Street Fighter V отключает встроенный механизм защиты Windows, поэтому мне показалось, что было бы полезно описать некие меры предосторожности, которые, вероятно, есть. То есть речь не только о safety, но в большей мере о security.

[aleksanderem]

К слову, такой же способ исполнения пользовательского кода в Ring0 используется и у меня: отключаем SMEP, сохраняем FPU-контекст и прыгаем на юзермодный код внутри __try..__except-блока (см. KbExecuteShellCode). А сейчас пишу обновление, чтобы напрямую работать с PTE-записями из юзермода (т.е., сможем открыть юзермоду всё ядерное пространство). С точки зрения секьюрности — полное ай-ай-ай! Но основная цель драйвера и заключается в том, чтобы максимально упростить выполнение необходимого кода в ядре и делать то, что нельзя.

[zanac]

ХР64 поддерживается? Собирать можно Mingw64? Есть желание скрестить с открытыми дровами на радеон с полярисом.

[aleksanderem]

ХР64 не поддерживается (не проверял, но, скорей всего, в ядре не хватит нужных экспортов, попробуйте), а про MinGW не подскажу, использую только MSVC. Если не секрет, что именно хотите реализовать и почему столь странный тулчейн и требование к 10 лет, как устаревшей, ОС?

[zanac]

Извините, ответил ниже.

[zanac]

Mingw работает на ХР, есть пакеты и для линукса, т.е. разработку можно вести где угодно. Я пропустил момент, когда можно было купить новые gtx 960/970 за небольшие деньги, сижу пока с радеоном 6850.
Проект — перенос открытых драйверов для радеон полярис.
Этот проект актуален и для владельцев 7ки — через год и она устареет.

[aleksanderem]

Тоже случайно ответил ниже… бывает!

[aleksanderem]

А почему именно ХР? Судя по карте, железо позволяет обновиться до Win10 и использовать официальный тулчейн без проблем, не заморачиваясь с поддержкой легаси. Или проблема именно в специфике открытых драйверов?

[zanac]

Потому, что ХР — лучшая ОС от микрософт, семерка чуть хуже. Десятка, гммм. Даром не надо. Потыкал в виртуалке и снес. Выбор gcc обусловлен тем, что драйвера под Линукс им собираются и решать косяки не поддерживаемого компилятора не собираюсь.
И некоторые игры на более новых ос работают некорректно.