> 10 лет назад, с точки зрения безопасности, микроядро на PC-архитектуре было не
> нужно. Оно было нужно 20+ лет назад, когда диски и сетевушки
> работали с PIO, а не с DMA, и оно нужно теперь,
> когда в процессорах начали появляться IOMMU:

Смотрю несколько иначе. Разграничить доступность коду только определённой областью доступа было нужно и вчера и сегодня, и будет нужно всегда. И дрова устройств - лишь частный случай такого кода. (а у x86 процов, кстати, есть аж 4 уровня защиты (protectiong rings) в защищённом режиме, и в самых распространённых ядрах/осях почему-то 2 средних были не у дел... а ведь это потенциал безопасности...)

> "Without IOMMU there is no security benefit of having a microkernel vs.
> having a good-old monolithic kernel.

Несколько голословно (но текст я прочитать не асилил). Попробую взять логически.
Есть монолит ядро, и в нём есть драйвер сетевухи. Этот драйвер может причинить много "пользы" внутри всего ядра, ибо монолит.
Если же сей код ограничить каким-то пространством доступа - то безопасности:
* добавится?
* убавится?
* не изменится?
Думаю, ответ очевиден. Следовательно, "no security benefit" != true

Если брать пример код на пользовательском уровне - то если одна прога не сможет иметь доступа к файлам другой - то это ли не добавляет безопасности? - Добавляет. Именно это и достигается в этой Qubes OS.

> А Qubes всё-таки в основном не о драйверах (хотя и это тоже,
> для NetVM и не только, при наличии IOMMU), а о VM'ах
> с приложениями. Поэтому есть смысл использовать Qubes даже на процессорах без
> IOMMU.

Естественно.
Но в том то и дело, что драйвера-недрайвера - это чисто субъективный стереотип, навязанный монолитным ядром.
Как насчёт драйвера мыльного аккаунта (Thunderbird)?
Или приложения для фильтрации траффика (modprobe xtables)?
И то, и другое - код. И то, и другое источник угроз безопасности. И то, и другое можно и нужно изолировать, предоставляя доступ лишь к необходимым для работы ресурсам.

А то, что там "под капотом" у прокладки "разговора" с железом (PIO, DMA, IOMMU) - это уже нюансы. У микроядра всё равно есть некоторая базовая часть-загрузчик-менеджер (собственно, МИКРО-ядро). И если нет IOMMU, то в помощь приложениям-драйверам будет подсистема ввода-вывода в этом микроядре (точно также, как и управление памятью тоже будет там). Приложения-дрова делают запрос/ответ об I/O не сами, а просят об этом микроядро. Медленнее, чем монолит, но профит очевиден.