TSS поле "i/o Map Base Adress". Механизм разрешений. Помогите разобраться.

[GrimHex]

В TSS есть поле "i/o Map Base Adress". Я понимаю, что для каждой задачи (имеющей свой TSS) можно запретить либо разрешить доступ к каждому из устройств.

Но не понимаю следующего. По адресу "i/o Map Base Adress" в памяти, для цели "запрета/разрешения", должны хранится значения битов для каждой из задач. Хотя служебная структура портов ввода вывода одна.

Либо для каждой задачи есть своя служебная структура с разрешениями устройств. Либо процессор переключает состояние битов при каждом переключении задачи. Как процессор это реализует?

[R71MT]

Сообщение от GrimHex

Как процессор это реализует?

"Permission Map" это статическое поле в TSS. Оно не обновляется процем при переключении задач, а биты в нём выставляются при создании задачи ядром. Когда IOPL задачи меньше CPL (обычно под юзером), этой карты вообще нет в TSS, что означает запрет на инструкции in/out. Вот как её отображает ядерный отладчик SYSER, в который я загрузил свою юм прожку:

>> tss
TR = 0028   BASE = 80042000   LIMIT = 20AB

LDT=0000  GS=0855  FS=5501  DS=0F56  SS=8B24  CS=8510  ES=EC8B
EAX=1875FFEC  EBX=FFFF02E8  ECX=FF1475FF  EDX=55FF8B00  EIP=001CC2C9
ESI=14C25DFF  EDI=55FF8B00  EBP=FFFF02E8  ESP=0875FF00  EFL=8B55FF8B

CR3 = 17CEF000
SS0 = 0010:F5D58DE0  SS1 = 4338:D0685000  SS2 = C483:FFFF33B5

I/O permission map.....:  BASE = 20AC,     SIZE = 0
INT redirection bit-map:  BASE = 80042068, SIZE = 32

                   0 1 2 3 4 5 6 7 - 8 9 A B C D E F
                   ------------------------------------
0x80042068  0400   0 0 1 0 0 0 0 0 - 0 0 0 0 0 0 0 0  0
0x8004206A  0018   0 0 0 0 0 0 0 0 - 0 0 0 1 1 0 0 0  1
0x8004206C  1800   0 0 0 1 1 0 0 0 - 0 0 0 0 0 0 0 0  2
0x8004206E  0000   0 0 0 0 0 0 0 0 - 0 0 0 0 0 0 0 0  3
0x80042070  0000   0 0 0 0 0 0 0 0 - 0 0 0 0 0 0 0 0  4
0x80042072  0000   0 0 0 0 0 0 0 0 - 0 0 0 0 0 0 0 0  5
0x80042074  0000   0 0 0 0 0 0 0 0 - 0 0 0 0 0 0 0 0  6
0x80042076  0000   0 0 0 0 0 0 0 0 - 0 0 0 0 0 0 0 0  7
0x80042078  0000   0 0 0 0 0 0 0 0 - 0 0 0 0 0 0 0 0  8
0x8004207A  0000   0 0 0 0 0 0 0 0 - 0 0 0 0 0 0 0 0  9
0x8004207C  0000   0 0 0 0 0 0 0 0 - 0 0 0 0 0 0 0 0  A
0x8004207E  0000   0 0 0 0 0 0 0 0 - 0 0 0 0 0 0 0 0  B
0x80042080  0000   0 0 0 0 0 0 0 0 - 0 0 0 0 0 0 0 0  C
0x80042082  0000   0 0 0 0 0 0 0 0 - 0 0 0 0 0 0 0 0  D
0x80042084  0000   0 0 0 0 0 0 0 0 - 0 0 0 0 0 0 0 0  E
0x80042086  0000   0 0 0 0 0 0 0 0 - 0 0 0 0 0 0 0 0  F

Здесь видно, что у "Permission Map" размер равен нуль, т.е. её вообще нет. Второй битмап "Redirection" - карта перенаправления прерываний. 32 её байта позволяют перенаправлять 32x8=256 юзерских интов. Каждый бит соответствует одному прерыванию, который отображается на соответствующий дескриптор в таблице(IDT). Если бит в битмапе взведён, то управление передаётся через дескриптор(IDT) обработчику защищённого режима. Когда бит сброшен, ЦП переназначает программное прерывание на таблицу IVT векторов прерываний х8086. Этот битмап используется только в режиме V86 процессора.

[GrimHex]

Сообщение от R71MT

"Permission Map" это статическое поле в TSS. Оно не обновляется процем при переключении задач, а биты в нём выставляются при создании задачи ядром. Когда IOPL задачи меньше CPL (обычно под юзером), этой карты вообще нет в TSS, что означает запрет на инструкции in/out. Вот как её отображает ядерный отладчик SYSER, в который я загрузил свою юм прожку:

>> tss
TR = 0028   BASE = 80042000   LIMIT = 20AB

LDT=0000  GS=0855  FS=5501  DS=0F56  SS=8B24  CS=8510  ES=EC8B
EAX=1875FFEC  EBX=FFFF02E8  ECX=FF1475FF  EDX=55FF8B00  EIP=001CC2C9
ESI=14C25DFF  EDI=55FF8B00  EBP=FFFF02E8  ESP=0875FF00  EFL=8B55FF8B

CR3 = 17CEF000
SS0 = 0010:F5D58DE0  SS1 = 4338:D0685000  SS2 = C483:FFFF33B5

I/O permission map.....:  BASE = 20AC,     SIZE = 0
INT redirection bit-map:  BASE = 80042068, SIZE = 32

                   0 1 2 3 4 5 6 7 - 8 9 A B C D E F
                   ------------------------------------
0x80042068  0400   0 0 1 0 0 0 0 0 - 0 0 0 0 0 0 0 0  0
0x8004206A  0018   0 0 0 0 0 0 0 0 - 0 0 0 1 1 0 0 0  1
0x8004206C  1800   0 0 0 1 1 0 0 0 - 0 0 0 0 0 0 0 0  2
0x8004206E  0000   0 0 0 0 0 0 0 0 - 0 0 0 0 0 0 0 0  3
0x80042070  0000   0 0 0 0 0 0 0 0 - 0 0 0 0 0 0 0 0  4
0x80042072  0000   0 0 0 0 0 0 0 0 - 0 0 0 0 0 0 0 0  5
0x80042074  0000   0 0 0 0 0 0 0 0 - 0 0 0 0 0 0 0 0  6
0x80042076  0000   0 0 0 0 0 0 0 0 - 0 0 0 0 0 0 0 0  7
0x80042078  0000   0 0 0 0 0 0 0 0 - 0 0 0 0 0 0 0 0  8
0x8004207A  0000   0 0 0 0 0 0 0 0 - 0 0 0 0 0 0 0 0  9
0x8004207C  0000   0 0 0 0 0 0 0 0 - 0 0 0 0 0 0 0 0  A
0x8004207E  0000   0 0 0 0 0 0 0 0 - 0 0 0 0 0 0 0 0  B
0x80042080  0000   0 0 0 0 0 0 0 0 - 0 0 0 0 0 0 0 0  C
0x80042082  0000   0 0 0 0 0 0 0 0 - 0 0 0 0 0 0 0 0  D
0x80042084  0000   0 0 0 0 0 0 0 0 - 0 0 0 0 0 0 0 0  E
0x80042086  0000   0 0 0 0 0 0 0 0 - 0 0 0 0 0 0 0 0  F

Здесь видно, что у "Permission Map" размер равен нуль, т.е. её вообще нет. Второй битмап "Redirection" - карта перенаправления прерываний. 32 её байта позволяют перенаправлять 32x8=256 юзерских интов. Каждый бит соответствует одному прерыванию, который отображается на соответствующий дескриптор в таблице(IDT). Если бит в битмапе взведён, то управление передаётся через дескриптор(IDT) обработчику защищённого режима. Когда бит сброшен, ЦП переназначает программное прерывание на таблицу IVT векторов прерываний х8086. Этот битмап используется только в режиме V86 процессора.

Спасибо, стало понятнее. Просто некоторая информация не дается с первого чтения.

Так вычитал, что есть два подхода для работы с устройствами в X86. Этот ответ касается "memory-mapped I/O". Второй подход — это "адресное пространство портов ввода-вывода". Чтобы уже не создавать новую тему...

1. Какой механизм защиты предусмотрен для "пространства портов ввода вывода"?
2. Драйверы используют "memory-mapped I/O" или "пространство портов ввода вывода"?

[Pavia]

Предлогаю в данной теме для карткости "адресса портов ввода вывода" сокращать до APIO.
memory-mapped I/O соответсвенно будет MMIO.
MMIO или APIO зависит от устройства. Старые устройства такие как PIC, PIT, 8042 используют APIO новые устройства такие как PCI, USB, APIC, HPeT используют MMIO.

MMIO закрывают от прикладных программ при помощи страниц. А драйвера отображают нужные адреса в свое адрестное пространство(АП). Или в АП ядра.

А APIO всего 65536 и они закрываются битовой картой. Ссылка на которую лежит в TSS(i/o Map Base Adress ссылается на Permission Map). При аппоратной смене задач i/o Map Base Adress не переключается. Вернее с пентиума 4 а может чуть раньше или позже был введён другой новый механизм аппоратного переключения задач, но в Рунете обънём мало кто знает.

[R71MT]

Сообщение от GrimHex

1. Какой механизм защиты предусмотрен для "пространства портов ввода вывода"?

В защищённом режиме всё держится на привилегиях..
CPL - Current Privelege Level - прописан в двух/младших битах селектора сегмента-кода текущей задачи (регистр CS). Для остальных программных секций DS/ES/SS/FS/GS эти биты [1:0] назвали RPL - Request Privelege Level. Соответственно RPL это запрошенный у системы уровень привилегий, а CPL это назначенная текущему коду привилегия - kernel(0) или user(3).

Когда система запускает процесс, для каждой из его секций в системной таблице-дескрипторов GDT создаётся свой дескриптор с характеристиками выделяемой секции. В этих дескрипторах в битах [14:13] есть поле DPL - Descriptor Privelege Level, которое определяет Ring дескриптора 0/3. Можно сказать, что по DPL система выставляет RPL/CPL в селекторах сегментных регистров.

Кроме того, в регистре флагов EFLAGS имеется 2-битное поле IOPL - уровень привилегий ввода-вывода, с которым выполняется текущая задача. Чтобы программный код мог обратиться к порту в/в, его CPL должен быть меньше/равно IOPL. К этому полю можно подобраться только имея CPL=0, т.е. из ядра.

Сообщение от GrimHex

2. Драйверы используют "memory-mapped I/O" или "пространство портов ввода вывода"?

..как уже сказал Pavia - это зависит от конкретного девайса.
Имеется общее для всех PCI устройств конфигурационное пространство. Каждому устройству в нём выделяется по 256-байт (у некоторых больше), где начиная со-смещения 10h лежат шесть BAR'ов - Base Address Registers.

Бит(0) в этих регистрах назвали RTE, и по нему система определяет куда перенаправлять запрос – на пространство портов I/O, или на адресное пространство MMIO. Если этот бит сброшен, то порты девайса лежат в MMIO. Если-же RTE=1, значит это древняя железяка с портами в своей тушке:

[Mikl___]

Зачем нужен драйвер и как написать простейший драйвер Несколько способов как из под Windows XP добраться до портов 42h, 43h, 61h, чтобы сыграть системным динамиком «Марш гладиаторов» Julius'а Fučík'а.

[GrimHex]

Предполагается, что нужно устанавливать разрешения для программ, работающих в "Ring 0" т.е. с максимальными привилегиями.

Если драйвер из "Ring 0" попытается обратится к другому устройству (не к тому, для которого он написан), — возникнет специфическая для ОС ситуация. ОС должна защищать от драйверов, в коде которых допущена эта ошибка.

Запрещает ли ОС драйверам доступ ко всем остальным устройствам (кроме родного для драйвера)?

[Pavia]

Сообщение от GrimHex

Запрещает ли ОС драйверам доступ ко всем остальным устройствам (кроме родного для драйвера)?

Виндоус и Линукс имеют монолитные ядра. Системный процесс один и имеет одно ядерное пространство. Все ядерные драйвера имеют доступ ко всем устройствам.

А вот драйвера которые сидят в прикладном пространстве к портам доступ не имеют. Они обращаются через API и/или сообщения к ядерным драйверам. К примеру драйвер принтера обращается к драйверу USB через usblib.h. А тот уже пишет в нужные порты.

В микроядерных ОС драйвера сидят каждый в своём процессе, т.е. у каждого свое АП. И тут уже можно разграничить доступ к портам.
Если не ошибаюсь так сделано ОС Миникс.

[Pavia]

Сообщение от GrimHex

ОС должна защищать от драйверов, в коде которых допущена эта ошибка.

Это не так страшно. Есть устоявшийся процесс разработки железа. Который требует иметь пути восстановления после сбоя. А любой автомат не должен зависать в одном состоянии. Так что одиночные сбои нестрашны. И плюс к тому что-бы выполнить хоть какую команду в железе надо сделать несколько записей в регистры, а это уже не так просто(т.е маловероятное событие).
Во-вторых, такие ОС как Линукс и Виндоус имеют механизмы защиты. Они просто добавили виртуализацию и держат по 2 ядра в активном состоянии.
Это не столь надёжно чем у микроядерных ОС, но это проще чем согласовать переделку 100 драйверов.

[GrimHex]

Сообщение от Pavia

Виндоус и Линукс имеют монолитные ядра. Системный процесс один и имеет одно ядерное пространство. Все ядерные драйвера имеют доступ ко всем устройствам.

А вот драйвера которые сидят в прикладном пространстве к портам доступ не имеют. Они обращаются через API и/или сообщения к ядерным драйверам. К примеру драйвер принтера обращается к драйверу USB через usblib.h. А тот уже пишет в нужные порты.

Являются ли драйверы из "Windows Driver Frameworks (WDF)" драйверами прикладного адресного пространства (т.е. не работающими в режиме ядра)?

Если в такой ОС как Windows много чего стандартизировано, то...

Отвечают ли "драйверы ядра" какому либо стандарту?

Сообщение от Pavia

Есть устоявшийся процесс разработки железа.

Для корпоративных интересов он действительно устоявшийся. А для всяких самоделкиных не очень. К примеру, если исследовать цель создания с нуля своей ОС, — почти неподъемный труд состоит в том чтобы поддерживать на уровне кода все нужные устройства.

Сообщение от Pavia

Это не так страшно. Есть устоявшийся процесс разработки железа.

По процессору можно почитать стандарты в "Software developer manual". А что читать, если нужна документация по железу устройств?

Заранее спасибо.