Теоретический вопрос про доступ к железу из юзермода

Тема в разделе "WASM.OS.DEVEL", создана пользователем ormoulu, 14 авг 2022.

  1. ormoulu

    ormoulu Well-Known Member

    Публикаций:
    0
    Регистрация:
    24 янв 2011
    Сообщения:
    1.208
    Сразу извиняюсь что в теме полный ноль.
    Вопрос такой: возможно ли технически спроецировать шину/порты/whatever железки, допустим видеокарту/видеопамять в пространство пользовательского процесса, полностью убрав обработку (к примеру) видео из ядра.
    Какие потенциальные недостатки у такого решения?
    Может быть, есть и ос, построенные на таком принципе?
    Или существуют какие-либо непреодолимые препятствия типа тайминга, синхронизации, дедлоков? Или современные процессоры позволяют доступ к железу исключительно из нулевого кольца?
     
  2. HoShiMin

    HoShiMin Well-Known Member

    Публикаций:
    5
    Регистрация:
    17 дек 2016
    Сообщения:
    1.406
    Адрес:
    Россия, Нижний Новгород
    Можно, конечно, только зачем?
    Процессору не принципиально, откуда ты стучишься к железу. Куда отобразишь память девайса - с такими правами и сможешь с ней общаться.
    С портами аналогично: выстави потоку EFLAGS.IOPL == 3, и сможешь стучать к портам из Ring3. В линуксе есть специальный сисколл iopl() для этого. На винде чуть посложнее, понадобится драйвер, который пропатчит IOPL.
    Просто непонятно, какой смысл. Чтобы что?
    В ядре работать с железками просто удобней: память ядра общая для всех процессов, а юзермод у каждого свой (если мы говорим о винде, линуксе и маке).
    А так, just 4 fun, конечно можно - отмапливай память железяки в свой процесс через условную MmMapIoSpaceEx + ремап в юзермод через IoAllocateMdl/MmProbeAndLockPages/MmMapLockedPagesSpecifyCache.
    Или даже проще: через ZwMapViewOfSection, отобразив \Device\PhysicalMemory с нужного адреса.
     
    Последнее редактирование: 14 авг 2022
    alex_dz, ormoulu и Mikl___ нравится это.
  3. ormoulu

    ormoulu Well-Known Member

    Публикаций:
    0
    Регистрация:
    24 янв 2011
    Сообщения:
    1.208
    Секурити, стабильность, масштабируемость.
    Проблема с одним драйвером не уронит всю систему.
     
  4. HoShiMin

    HoShiMin Well-Known Member

    Публикаций:
    5
    Регистрация:
    17 дек 2016
    Сообщения:
    1.406
    Адрес:
    Россия, Нижний Новгород
    …которых не будет в юзермоде.
    Например, тебе нужен юзермодный видеодрайвер. Как процесс сможет им воспользоваться?
    Сейчас потоку надо уйти в ядро, где он попадёт в код видеодрайвера, и драйвер в контексте вызвавшего его потока будет общаться с девайсом.
    Отлично, убираем ядерную прослойку и уносим код драйвера в юзермодную дллку, а также мапим память девайса в наш графический процесс.
    Теперь процесс может напрямую читать и писать что-то в память видеокарты. Он может это сделать даже в обход драйвера, даже сделать это случайно.
    Кто-то ошибся в указателе и случайно записал в память видеокарты команду увеличить напряжение на двадцать вольт.
    Или, будь это юзермодный драйвер диска, баг в программе легко устроит тебе format C:. Оно тебе надо? Оно тебе не надо. Поэтому драйвера уносят в ядро, чтобы никто случайно или намеренно не мог свалить всю систему.
    А ещё юзермодный софт имеет свойство падать, а общение с аппаратурой зачастую неатомарно: чтобы сделать что-то, чаще всего нужно послать несколько команд. Что будет, если твоё приложение пошлёт три команды из пяти и упадёт? Девайс останется в неконсистентном состоянии, и лучше нам не проверять, чем это закончится.
     
  5. ormoulu

    ormoulu Well-Known Member

    Публикаций:
    0
    Регистрация:
    24 янв 2011
    Сообщения:
    1.208
    Если формат с: или команду увеличить напряжение подаст ядерный драйвер, что меняется?
    Лишь то, что крашится вся система.
    Юзермодный софт не имеет свойства падать лишь по причине того что он юзермодный. Юзермодный софт падает по причине того что он хреново написан.
    Уже несколько лет как гугл и майкрософт много что из ядра перенесли в юзермод. Отказов стало сильно больше?
     
  6. HoShiMin

    HoShiMin Well-Known Member

    Публикаций:
    5
    Регистрация:
    17 дек 2016
    Сообщения:
    1.406
    Адрес:
    Россия, Нижний Новгород
    Но он не подаст, если в нём нет уязвимостей, через которые это смогут сделать. Других способов послать что-то девайсу у пользовательского софта нет.
    Открыв память девайсов и порты юзермоду, ты даёшь злоумышленнику карт-бланш: отныне никто не стоит между ним и железом. Отказ всей системы или даже повреждение железа в этом случае можно будет сделать в пару строчек, не имея никаких привилегий.
    Железо не знает ни про какие права доступа, кто угодно сможет прочитать или записать любой сектор на диске, утащив чувствительные данные, и никто не сможет этому помешать.
    К сожалению, я не знаю ни одного примера. Все драйвера, вся графика, абсолютно всё, что работает с железом во всех операционках, живёт в ядре и никогда не смотрит в юзермод.
     
    Последнее редактирование: 14 авг 2022
  7. ormoulu

    ormoulu Well-Known Member

    Публикаций:
    0
    Регистрация:
    24 янв 2011
    Сообщения:
    1.208
    Впрочем, какая разница )
    Мой вопрос был про теоретическую возможность, спасибо за ответ.
     
  8. algent

    algent Member

    Публикаций:
    0
    Регистрация:
    11 апр 2018
    Сообщения:
    100
    Вообще-то, это вопрос из серии - зачем нужна ОС.
    Просто подумайте над смыслом слов:
    "разделяемый ресурс"
     
  9. Rockphorr

    Rockphorr Well-Known Member

    Публикаций:
    0
    Регистрация:
    9 июн 2004
    Сообщения:
    2.615
    Адрес:
    Russia
    MSDOS была именно такой

    все приблуды защищенного режима для поддержки многопользовательской работы
     
  10. ormoulu

    ormoulu Well-Known Member

    Публикаций:
    0
    Регистрация:
    24 янв 2011
    Сообщения:
    1.208
    Нет, не была.

    Если под этим понимать "работы не только суперадмина, который заодно программист, понимает все что происходит в системе и имеет к ней персональный физически защищённый доступ", то вероятно да.
     
  11. UbIvItS

    UbIvItS Well-Known Member

    Публикаций:
    0
    Регистрация:
    5 янв 2007
    Сообщения:
    6.042
    принципиальная разница в скорости - юзермод тормознутей, но если ядро затачивается лишь под один процесс - проблемы тормозов при переключение контекстов ужо нет.. глянь, например, юникерны - темка весьма перспективная - тот же видео редактор в форме юникерна будет просто гоночным мотоСИклем в сравнение с обычным десктопным. :)
     
    ormoulu нравится это.
  12. R81...

    R81... Active Member

    Публикаций:
    0
    Регистрация:
    1 фев 2020
    Сообщения:
    141
  13. Rockphorr

    Rockphorr Well-Known Member

    Публикаций:
    0
    Регистрация:
    9 июн 2004
    Сообщения:
    2.615
    Адрес:
    Russia
    чем же она вам не угодила то???
     
  14. TrashGen

    TrashGen ТрещГен

    Публикаций:
    0
    Регистрация:
    15 мар 2011
    Сообщения:
    1.173
    Адрес:
    подполье
    Тем, что в синий экран не падала:acute:
     
  15. HoShiMin

    HoShiMin Well-Known Member

    Публикаций:
    5
    Регистрация:
    17 дек 2016
    Сообщения:
    1.406
    Адрес:
    Россия, Нижний Новгород
    Часть способов подходит и для x64, но для этого ты уже должен иметь доступ в ядро.
    Дать юзермоду доступ к портам на современной 64х-битной винде без драйверов нельзя. Но если есть драйвер, можно пропатчить EFLAGS.IOPL в KTRAP_FRAME желаемого потока, и он получит в юзермоде доступ к портам и инструкциям cli/sti.
     
  16. ormoulu

    ormoulu Well-Known Member

    Публикаций:
    0
    Регистрация:
    24 янв 2011
    Сообщения:
    1.208
    Да всем она была хороша.

    Если что, вопрос не про мсдос/Винду/Линукс/етс.
    Вопрос про принципиальную возможность на современном железе. Есть ли технические ограничения или вопрос лишь в программной реализации.
     
  17. comrade

    comrade Константин Ёпрст

    Публикаций:
    0
    Регистрация:
    16 сен 2002
    Сообщения:
    232
    Адрес:
    Russian Federation
    Встречный вопрос: зачем? Цели абстракции и изоляции, реализуемые операционной системой, это:

    (а) resource sharing/arbitration - то есть ресурс (видеокарту/"железо") ограничен в своих возможностях; при спроса к ресурса с нескольких процессов должен быть арбитр этого ресурса, который по заданым правилам будет распределять мощности этого ресурса среди n-ных потребителей

    (b) authoritative management - не уверен что правильную терминологию использую, но банально - если юзерский процесс упал, то система в целом должна стабильна с этим справиться и отставить ресурс ("железо") в рабочем состояние. Традиционно эту функцию реализовало разделение на ядро (ring-0) и "юзерские процессы" (ring-3). Ядро следит и отвечает за стабильность системы, изолирую потенциально дефектные части системы с свою среду (ring-3).

    Эти слои накладывают свою стоимость (с точки зрение производительности).