Судя по доле Windows на серверах, этот Unified page cache и IRP не особо то и нужен

Настолько не нужен. что в итоге введен в почти всех производных юникса. Суть в том, что оригинальные интерфейсы, вроде open/read/write очень устарели, из-за чего кучу функций работают через fcntl/ioctl и состояния у файла, в то время, как винда с бородатых времен имеет продвинутую подержку асинхронных a.k.a. overlapped операций без состояния. А тот же epoll/kqueue в виде io completion ports было в винде начиная с 3.5. А права доступа — это просто забей, их почти не было в юниксах. Или вот еще: совсем недавно разбирался с интерфейсами разделяемой памяти, и внезапно узнал, что из всех никсов вот-вот начинает подбираться к уровню интерфейсов NT один линукс — все остальные только начинают выбираться из каменного века.

Да, MS мог бы теоретически наглухо выдавить никсы с серверов, если бы сделал что-то аскетичное. Но он предпочел придерживаться вендор лока через поддержку переусложненной ОС-и с недокументированными фичами — и проиграл. Объективно же архитектура NT на голову выше никсов, а всё переусложнение начинается в пользовательском режиме.

Начиная с версии 1.0 Windows - это полноценная операционная система. В ней свой формат исполняемых файлов, реализованы загрузка и выгрузка модулей, выделение памяти, переключение задач и т.д

European MS-DOS 4.0 имел многозадачность и формат исполняемых файлов NE.

Многие компоненты привязаны к GUI, например COM работает через отправку сообщений скрытому окну

Оконный объект, создаваемый CreateWindow, еще не является GUI. Это относительно легковесный объект ядра с атрибутами и очередью сообщений. GUI к оконному объекту привязывается только после ShowWindow.

Это относительно легковесный объект ядра с атрибутами и очередью сообщений. GUI к оконному объекту привязывается только после ShowWindow.

То есть по сути окна – это порты для обмена сообщениями в переделах сеанса, как в микроядерной ОС? А прозрачная интеграция с GUI прикручена сбоку для совместимости?

Блин, это круто.

Суть в том, что оригинальные интерфейсы, вроде open/read/write очень устарели

Есть замеры что open/read/write работает существенно медленнее, чем асинхронный ввод-вывод? Кроме специфичных задач вроде сервера базы данных в них особо нет необходимости.

К тому же они уже давно есть в Линуксе (AIO, epoll).

А права доступа — это просто забей, их почти не было в юниксах.

Они на сервере особо и не нужны. На сервере установлено только доверенное ПО и проверка доступа в основном нужна для запросов извне. Проверка прав доступа часто делается в прикладном ПО для конкретных задач.

Или вот еще: совсем недавно разбирался с интерфейсами разделяемой памяти, и внезапно узнал, что из всех никсов вот-вот начинает подбираться к уровню интерфейсов NT один линукс

Есть mmap и shm_open (пример). В Windows NT всё так перемудрено, что в ReactOS сделать управление памятью в ядре никак не могут.

все остальные только начинают выбираться из каменного века.

В BeOS/Haiku изначально была поддержка разделяемой памяти (документация). Сделано намного лаконичнее, чем в NT. Каждый блок виртуальной памяти является объектом ядра «area». С помощью программы listarea можно вывести все area отображённые в адресное пространство процесса.

Объективно же архитектура NT на голову выше никсов, а всё переусложнение начинается в пользовательском режиме.

Всё полезное что там было уже реализовано в других системах, а всё остальное - переусложнение и не нужно. Избыточная сложность - уязвимость.

European MS-DOS 4.0 имел многозадачность и формат исполняемых файлов NE.

Которая была никому не нужна. Использовали либо Windows, либо оригинальную DOS без всего этого. MS-DOS 4.0 использовала наработки Windows.

То есть по сути окна – это порты для обмена сообщениями в переделах сеанса, как в микроядерной ОС? А прозрачная интеграция с GUI прикручена сбоку для совместимости?

Для портов обмена сообщениями уже есть LPC (NtCreatePort). Окна намертво пришиты к GUI, у них обязательно есть позиция, регионы видимости и обновления и т.п. Они просто могут не рисоваться когда не видны. Для ознакомления можно посмотреть исходники ReactOS (window.c, struct WND).

Есть замеры что open/read/write работает существенно медленнее, чем асинхронный ввод-вывод? Кроме специфичных задач вроде сервера базы данных в них особо нет необходимости.

Ну ты попробуй сам IO для ядра запроектировать, у тебя всё равно появится необходимость в асинхронных объектах. Потому что IO по своей сути штука асинхронная.

Вопрос только в том, будешь ты делать это на подпорках или сразу запроектируешь унифицированный интерфейс, в который можно инкапсулировать IO любой природы без костылей и изоленты.

К тому же они уже давно есть в Линуксе (AIO, epoll).

Настолько есть, что в линуксе до сих проблема приоритизировать доступ к свопу, например.

Объект IO создаёт самое главное – контекст для проведения операции.

Окна намертво пришиты к GUI, у них обязательно есть позиция, регионы видимости и обновления и т.п.

Позиция это просто 4 числа. Обработка регионов видимости всегда noop, пока окно unmapped.

Это мелочи на самом деле.

В целом ваша позиция достаточно непоследованная, как мне представляется:

WinAPI – это хорошо, а когда это WinAPI используют чтобы не плодить лишних сущностей – это плохо.

В классической винде (3.x, 9x) никаких NtCreatePort нет, а COM есть. Вывод? С учётом тогдашней ситуации, всё правильно сделали.

Для ознакомления можно посмотреть исходники ReactOS (window.c, struct WND).

Для ознакомления с реализацией Windows NT смотреть ReactOS? Оригинально… Можно еще в wine заглянуть.

Лучше тогда скачать сами знаете что…

Нет, венде до такой скорости еще далеко, работа с диском видимо от доса на инт13х.

К тому же они уже давно есть в Линуксе (AIO, epoll).

+ io_uring появился, на что теперь жаловаться можно не совсем понятно...

В целом ваша позиция достаточно непоследованная, как мне представляется:

Я за то, чтобы GUI не был в ядре. win32k.sys - это неиссякаемый источник уязвимостей, понижающий безопасность серверных систем. Можно вообще сделать как в Haiku, когда дескрипторы окон управляются в самом процессе и передача сообщений происходит без посредства каких либо сторонних процессов или специальных модулей ядра.

С учётом тогдашней ситуации, всё правильно сделали.

Да я в общем то не против. Только зачем тащить на сервер дырявый win32k.sys?

Сделать-то можно как угодно, но всё упирается в производительность.

В Windows (не NT) была жестокая борьба практически за каждую страницу памяти, чтобы впихнуться в потребительский рынок того времени. Вплоть до того, что polling любого вида был под запретом, только обработка событий. Потому что polling препятствует вытеснению страниц на диск.

Известный пример из литературы:

Часы в панели задач возводят таймер, по истечении таймера делают invalidate region и снимают таймер.

Если WM_PAINT не пришло, значит часы не видимы на экране, и дальше можно ни о чем не беспокоиться.

При получении WM_PAINT (часы снова стали видимы) – после отрисовки часы снова возводят таймер.

Другой пример: события мыши не стоят в очереди, а на лету генерируются в процессе чтения сообщений. Если окно не ждёт в обработчике сообщений в данный момент, то и лишнюю работу по созданию событий никто не делает.

(Последнее, кстати, наконец-то реальный пример оптимизации кода, которая не возможна или бессмыслена в клиент-серверной модели. В отличие от типичных аргументов всех неучей, у которых тулкиты тормозят по вине иксов.)

Из таких мелочей складывась разработка.

Когда команда Катлера запроектировала серверное ядро, всё было прекрасно на бумаге, кроме того факта, что честная микроядерная реализация GUI на этом ядре тормозила на актуальном железе.

Часы в панели задач возводят таймер, по истечении таймера делают invalidate region и снимают таймер.

Если WM_PAINT не пришло, значит часы не видимы на экране, и дальше можно ни о чем не беспокоиться.

При получении WM_PAINT (часы снова стали видимы) – после отрисовки часы снова возводят таймер.

Я так тоже делаю в своих проектах. Это позволяет избежать шквала сообщений таймера при медленной отрисовке и позволяет не нагружать систему когда графический объект не видно. Также это лучше подходит для модели памяти со сборщиком мусора: не нужно обрабатывать оповещения об удалении визуального объекта из дерева объектов.

Другой пример: события мыши не стоят в очереди, а на лету генерируются в процессе чтения сообщений.

В результате окно зависает намертво если обработка сообщения отсылает новое сообщение. В Haiku всё работает. Я так и не нашёл способа избежать зависания. Надеялся на WM_ENTERIDLE, но оно не всегда присылается. В итоге пришлось сделать обработку в главном цикле и смириться с зависанием при открытии меню и модальных окон.

честная микроядерная реализация GUI на этом ядре тормозила на актуальном железе.

Это уже 20 лет не является проблемой. Сейчас ничего не мешает сделать графику в пространстве пользователя. Ссылаться на проблемы 199x годов в 2020 году - это странно.

Я не следил за уязвимостями

Только зачем тащить на сервер дырявый win32k.sys?

В чем именно он дырявый? Актуальные уязвимости за последние N лет?

О как объеме кода идёт речь и почему этот код было невозможно отладить за 20 лет? (Если было.)

В результате окно зависает намертво если обработка сообщения отсылает новое сообщение. В Haiku всё работает. Я так и не нашёл способа избежать зависания. Надеялся на WM_ENTERIDLE, но оно не всегда присылается. В итоге пришлось сделать обработку в главном цикле и смириться с зависанием при открытии меню и модальных окон.

Ничего не понял. При чем тут мышь?

Это уже 20 лет не является проблемой. Сейчас ничего не мешает сделать графику в пространстве пользователя.

Сейчас тенденция обратная, все всё засовывают в ядро ради +5% процентов в бенчмарке. (Даже если эти проценты выдуманные, как под вяленым.)

В чем именно он дырявый? Актуальные уязвимости за последние N лет?

Вот пример недавнего былинного фейла, когда ядро взламывают через создание палитры. И подобных уязвимостей там ещё полно.

При чем тут мышь?

При том, что сообщения мыши вообще не приходят, если очередь сообщений не пуста.

Даже если эти проценты выдуманные, как под вяленым.

Wayland уже в ядро засовывают? Я что-то пропустил?

При том, что сообщения мыши вообще не приходят, если очередь сообщений не пуста.

Всё равно не ясен юзкейс.

Wayland уже в ядро засовывают? Я что-то пропустил?

Драйвера давно в ядре.

Всё равно не ясен юзкейс.

Нужно сделать фоновую задачу, которая работает в оконном потоке (в целевой среде многопоточность не поддерживается). WM_TIMER слишком медленный, а вызов задачи из главного цикла не работает если есть открытые меню или модальные окна (они рекурсивно запускают свой цикл обработки сообщений).

Драйвера давно в ядре.

В ядре только базовый mode setting и управление видеопямятью. Основная логика видеодрайвера находится в модуле пользовательского режима.Это справедливо для Windows, Linux и Haiku.

In a sharply ironic twist, however, this architectural change turned out to have an inverse effect on the security of the remaining graphics code that stayed behind in the kernel. Refactoring printer drivers and moving them into user space created an entire new attack surface, consisting of the new interface created between kernel-mode graphics code and the driver code that had now been relocated to user space. Kernel-mode code that once was secure could now be made to fail in various ways through influence from printer driver code now running in user mode, which is far more open to tampering.

Иронично.

Но если запустить win32k.sys отдельным процессом, баг никуда не денется, и атакующий получит привилегии этого процесса. А они в любом случае будут не маленькие, даже если и не уровня SYSTEM. Но иметь доступ к оконной системе и вмешиваться в работу всего UI уже само по себе не мало.

В ядре только базовый mode setting и управление видеопямятью. Основная логика видеодрайвера находится в модуле пользовательского режима.Это справедливо для Windows, Linux и Haiku.

Суть в том, что сначала выполняется разный boilerplate (который и требует переключения контекстов много раз), не имеющий отношения к бизнес-логике, а только к обеспечению защиты, и затем прикладной код напрямую взаимодействует с возможностями GPU.

Это верно как для Wayland, так и для X11. Поэтому «ускорения» там сомнительные.

А они в любом случае будут не маленькие

Зачем GUI серверу особые привилегии? Его задача: принимать команды и рисовать на экране, а также распределять сообщения ввода. У него привелегий наоборот должно быть меньше, чем у обычных программ.

а вызов задачи из главного цикла не работает если есть открытые меню или модальные окна (они рекурсивно запускают свой цикл обработки сообщений).

А. Ну, это не имеет отношения к особенностям обработки мыши, которые я упоминал.

Использование рекурсивных циклов сообщений было сомнительной идеей с самого начала. Не знаю, почему выбран этот дизайн.

Для модального диалога можно создать собственный класс, переопределить в нём WndProc и вызывать оттуда обработчик задачи, а остальные сообщения машрутизировать в дефолтный обработчик диалога. Насчёт меню – не знаю.

а также распределять сообщения ввода

А это маленькие привилегии что ли?

Можно считывать конфиденциальную информацию прямо из окон. Узнать пароли сайтов, серверов, локальных машин, приватных ключей и т.п.

Тут и SYSTEM не нужен – он не самоцель.

А. Ну, это не имеет отношения к особенностям обработки мыши, которые я упоминал.

Имеет прямое отношение. Если бы сообщения ввода, отрисовки и таймера по честному вставлялись в очередь, то самовызывающиеся сообщения работали бы без проблем. Причём для избежания шквала сообщений можно не вставлять сообщение ввода, если оно уже есть в очереди. Экономия на спичках которая привела к кривому дизайну и неожиданным проблемам.

Использование рекурсивных циклов сообщений было сомнительной идеей с самого начала. Не знаю, почему выбран этот дизайн.

Рекурсивные циклы сообщений необходимы для синхронных диалогов и прочих синхронных операций. Без них придётся писать асинхронный код и нельзя будет просто вызвать MessageBox или диалог открытия файла.

Можно считывать конфиденциальную информацию прямо из окон.

На сервере окна не нужны, кроме невидимых окон для сообщений. GUI серверу даже про содержимое очереди сообщений знать не обязательно (app_server в Haiku например не знает, для очереди сообщений используется объект ядра port).

То есть по сути окна – это порты для обмена сообщениями в переделах сеанса, как в микроядерной ОС? А прозрачная интеграция с GUI прикручена сбоку для совместимости?

Не знаю при чем тут микроядро — очереди сообщений, например, есть и в никсах. Это вполне себе монолит. Просто, маленький кусок гуевой подсистемы используется для общения процессов.

Рекурсивные циклы сообщений необходимы для синхронных диалогов и прочих синхронных операций. Без них придётся писать асинхронный код и нельзя будет просто вызвать MessageBox или диалог открытия файла.

Хорошо, скажу иначе. Тогда нужно было делать честные рекурсивные циклы сообщений с повторным вхождением в ту же самую процедуру цикла, а не в физически другой код.

Имеет прямое отношение. Если бы сообщения ввода, отрисовки и таймера по честному вставлялись в очередь, то самовызывающиеся сообщения работали бы без проблем. Причём для избежания шквала сообщений можно не вставлять сообщение ввода, если оно уже есть в очереди. Экономия на спичках которая привела к кривому дизайну и неожиданным проблемам.

Так вы же в само тело цикла вставляете свой код, как я понял. Проблема в том, что вы не имеете возможности внедриться в произвольное тело цикла произвольной библиотеки (стандартных контроллов винды или любой другой).

GUI серверу даже про содержимое очереди сообщений знать не обязательно

Каким образом он маршрутизирует сообщения в окна?

Каким образом он маршрутизирует сообщения в окна?

Отсылает сообщение в соответствующую ядерную очередь и всё. Координаты видимых окон, текущий фокус и прочая необходимая информация у него имеется. Читает из очереди процесс владелец очереди. Передача сообщений между процессами происходит непосредственно без участия GUI сервера. Можно сделать права у очереди так чтобы кроме процесса владельца очереди никто не мог из неё читать, только писать.

Тогда нужно было делать честные рекурсивные циклы сообщений с повторным вхождением в ту же самую процедуру цикла, а не в физически другой код.

Цикл обработки меню содержит свою логику, можно в коде Wine и ReactOS посмотреть. Использование самовызывающихся сообщений более универсально. Главный цикл вообще ничего не должен содержать кроме GetMessage, TranslateMessage, DispatchMessage.

Так вы же в само тело цикла вставляете свой код, как я понял.

Изначально я делал обработку шага фоновой задачи в обработчике сообщений и отсылал это сообщение опять. В таком случае в главном цикле никакой логики нет и не важно из какого цикла сообщений это работает. К сожалению данный подход без зависаний работает только для WM_TIMER, но у него слишком низкая частота генерации.

В чем именно он дырявый? Актуальные уязвимости за последние N лет?

Вот ещё:

• 2019, Use after free в CreateWindowEx.

• 2019, баг CreatePopupMenu (Что делает меню в win32k.sys??? Оно без проблем могло быть реализовано в user32.dll как это сделано в Wine).

Есть ещё уязвимости за 2020 год без выпущенных патчей.

Есть замеры что open/read/write работает существенно медленнее, чем асинхронный ввод-вывод?

Конечно нет. Дело в не «быстрее», а в том, какие возможности они дают. Сравни аргументы CreateFile/ReadFile с open/read.

К тому же они уже давно есть в Линуксе (AIO, epoll)

Вот именно, что «уже есть». А в винде они всегда были.

Они на сервере особо и не нужны. На сервере установлено только доверенное ПО и проверка доступа в основном нужна для запросов извне. Проверка прав доступа часто делается в прикладном ПО для конкретных задач

Ага, и потому костылят SELinux с докерами?

Есть mmap и shm_open (пример). В Windows NT всё так перемудрено, что в ReactOS сделать управление памятью в ядре никак не могут

Да, я пришел к тому, что shm_open — это единственный адекватный способ. Однако, передача разделяемой памяти другому процессу может быть проблематичной. По хорошему мы должны делать shm_unlink сразу после mmap, но такое поведение может привести к тому, что на некоторое короткое время все процессы сделали unmap/завершились при работающем процессе-получателе. То есть, я должен ждать момента, когда процесс-получатель 100% сделал shm_open—mmap—shm_unlink, и только тогда можно разрешать unmap. Есть и второй вариант — не делать shm_unlink, течь памятью, и потом не иметь возможности на многих никсах эти утекшие объекты закрыть. Во фряхе, например, совсем недавно сделали интерфейсы для запроса списка объектов разделяемой памяти. В лине чуть раньше сделали.

Всё полезное что там было уже реализовано в других системах, а всё остальное - переусложнение и не нужно

Ну да. Правда, не во всех и не всё. Но остается сам факт того, что NT заметно опередил свое время.

Конечно нет. Дело в не «быстрее», а в том, какие возможности они дают. Сравни аргументы CreateFile/ReadFile с open/read.

А например какие возможности при этом доступны в Windows и отсутствуют в Linux?

Окна намертво пришиты к GUI, у них обязательно есть позиция, регионы видимости и обновления и т.п. Они просто могут не рисоваться когда не видны. Для ознакомления можно посмотреть исходники ReactOS (window.c, struct WND)

Ну, и? Да, структура большая, но в основном заполняется она значениями по умолчанию, пустыми дескрипторами/ссылками.

Ну, и?

Простор для различных багов и эксплоитов. Неприемлемо для серверной ОС.

Про popup menu что-то совсем жестко. Это все должно обрабатываться в юзерспейсе.

win32k.sys - это неиссякаемый источник уязвимостей, понижающий безопасность серверных систем. Можно вообще сделать как в Haiku, когда дескрипторы окон управляются в самом процессе и передача сообщений происходит без посредства каких либо сторонних процессов или специальных модулей ядра

win32k.sys в мир не смотрит. Если ты про то, что непривелигированный пользователь что-то натворит — а не ты ли чуть выше писал, что на сервер должен стоять только доверенный софт?

Когда команда Катлера запроектировала серверное ядро, всё было прекрасно на бумаге, кроме того факта, что честная микроядерная реализация GUI на этом ядре тормозила на актуальном железе

Они хотели сделать объектно-ориентированный рай, где приложения передают друг другу окна с документами. OLE, ActiveX — вот это всё. Проблема в том, что модель оказалась неудобной, потому что кроме одного окна еще много чего нужно, а большинство приложений работают в рамках только своего процесса, и в итоге переключения контекстов ядерного GUI оказываются бессмысленными. Потому игры и Qt/GTK/etc не пользуются ядерным GUI, отрисовывая всё в единственное окно.

То есть, я должен ждать момента, когда процесс-получатель 100% сделал shm_open—mmap—shm_unlink, и только тогда можно разрешать unmap.

В чём проблема? Можно сделать поток в процессе-получателе который будет обрабатывать сообщения передачи разделяемой памяти и ожидать окончания обработки сообщения.

Чем подход Windows принципиально лучше?

Но остается сам факт того, что NT заметно опередил свое время.

Multics вообще опередила своё время так что до сих пор ей нет аналогов, например она умеет разделятся и объединяться между несколькими компьютерами без остановки работы. В ней впервые появилась потоки, поддержка нескольких процессоров, динамическая линковка (в UNIX долгое время её не было), виртуальная память и файлы отображаемые в память, проверки доступа, иерархическая файловая система. Multics - это первая настоящая операционная система. В ядре NT не было ничего принципиально нового и важного по сравнению с другими системами того времени. Это вообще по сути клон OpenVMS адаптированный для работу с WinApi.

Конечно нет. Дело в не «быстрее», а в том, какие возможности они дают. Сравни аргументы CreateFile/ReadFile с open/read.

А например какие возможности при этом доступны в Windows и отсутствуют в Linux?

Настройки прав доступа и запрос желаемого доступа к файлу (чтобы открыть его только для запис или или только для запроса метаинформации), и асинхронные stateless операции.

Простор для различных багов и эксплоитов. Неприемлемо для серверной ОС

Если такой логике следовать, то линь неприемлимо использовать для сервера.

win32k.sys в мир не смотрит.

А программы его использующие смотрят и могут содержать уязвимости позволяющие запустить произвольный код внутри процесса. У win32k.sys относительно постоянные номера системных вызовов, так что к нему легко обратиться из эксплоита и ASLR, PIC не помогут.

Если такой логике следовать, то линь неприемлимо использовать для сервера.

В пространстве ядра Линукса нету таких хитроумных и криворуких компонентов как win32k.sys. Лишние компоненты легко убрать (например ALSA на сервере не нужна).

В чём проблема? Можно сделать поток в процессе-получателе который будет обрабатывать сообщения передачи разделяемой памяти и ожидать окончания обработки сообщения.
Чем подход Windows принципиально лучше?

Тем, что я могу кинуться дескриптором в другой процесс, а дальше уже система сама при необходимости освободит объект.

Multics - это первая настоящая операционная система. В ядре NT не было ничего принципиально нового и важного по сравнению с другими системами того времени

Какими «другими»? Назови мне систему, которой пользовались больше двух человек, и которая была сравнима с NT? Да, мультикс крут, но не сыскал успеха, потому что был сложен. Для своего времени, по крайней мере.

Сомневаюсь, что отдел разработки ядра имел какое-то отношение к COM, OLE и вот этому всему.

В пространстве ядра Линукса нету таких хитроумных и криворуких компонентов как win32k.sys. Лишние компоненты легко убрать (например ALSA на сервере не нужна)

Ага, идею понял: ты хочешь беспощадно резать систему. А что делать, если админ еще не знает, какой набор софта будет на системе стоять? Типичная такая ситуация с докером, где черт знает что пригодится. Пересобирать каждый раз с новыми настройками ядро, потому что понадобилась какая-то там фича?

Также, как я понимаю, если бы в винде был некий переключатель «отключить сисколы win32k.sys», то ты бы сказал, что это годная для сервера система?

Сомневаюсь, что отдел разработки ядра имел какое-то отношение к COM, OLE и вот этому всему

Если и не имел прямого, то получал сверху указания. А иначе назови мне вторую систему с GUI в ядре.

GUI засунули в загружаемый модуль ядра, потому что в юзерспейсе оно тормозило. У дизайну ядра и подсистемы IO этот прискорбный факт имеет мало отношения.

Пересобирать каждый раз с новыми настройками ядро, потому что понадобилась какая-то там фича?

Зачем пересобирать? Просто не загружать модули ядра.

А иначе назови мне вторую систему с GUI в ядре.

Kolibri. И наверное всё.