Board.KolibriOS.org

Official KolibriOS board
It is currently Thu Nov 14, 2019 11:35 am

All times are UTC+03:00




Post new topic  Reply to topic  [ 24 posts ]  Go to page Previous 1 2
Author Message
 Post subject: Re: User-accessible MMIO
PostPosted: Sat Jan 02, 2010 2:54 pm 
Offline
Kernel Developer
User avatar

Joined: Fri Aug 14, 2009 1:46 am
Posts: 1351
В данном случае при компиляции ядра был установлен адрес моей видеокарты
mmpi_pci_addr = 0х100 ; (b1.d0:f0)
Важно: все svn-сорцы и бинарники должны идти с предустановленным mmpi_pci_addr = -1,
для блокировки пользовательского доступа ко всем MMIO-ресурсам
Attachment:
sceen.png
sceen.png [ 47.3 KiB | Viewed 3672 times ]

_________________
Узкий специалист подобен флюсу: полнота его - односторонняя.
Козьма Прутков


Top
   
 Post subject: Re: User-accessible MMIO
PostPosted: Sat Jan 02, 2010 6:08 pm 
Offline
Kernel Optimizer
User avatar

Joined: Mon Jan 16, 2006 7:58 pm
Posts: 657
Код pci32.inc можно добавить на SVN в trunk?


Top
   
 Post subject: Re: User-accessible MMIO
PostPosted: Sat Jan 02, 2010 6:13 pm 
Offline
Kernel Developer
User avatar

Joined: Fri Aug 14, 2009 1:46 am
Posts: 1351
<Lrz> wrote:
Код pci32.inc можно добавить на SVN в trunk?


Залил (с 5-й попытки :( )

_________________
Узкий специалист подобен флюсу: полнота его - односторонняя.
Козьма Прутков


Top
   
 Post subject: Re: User-accessible MMIO
PostPosted: Sat Jan 02, 2010 10:35 pm 
Offline

Joined: Wed Mar 26, 2008 12:44 pm
Posts: 225
art_zh wrote:
Залил (с 5-й попытки :( )

А build.bat в корневой директории зачем оставил?

И кстати, раз уж это не является необходимым сервисом (как я понял, только для облегчения разработки драйверов), то почему бы не оформить это в виде драйвера, ведь все используемые процедуры доступны и из драйвера. Кому надо, тот его загрузит. А так - будет лежать балластом в ядре. Кроме того, прямой доступ из usermode к устройствам в обход драйвера - не самый безопасный вариант.


Top
   
 Post subject: Re: User-accessible MMIO
PostPosted: Sun Jan 03, 2010 1:07 am 
Offline
Kernel Developer
User avatar

Joined: Fri Aug 14, 2009 1:46 am
Posts: 1351
tsdima
Мусор от первой закачки прибрал.

Насчет драйвера.
Добавляя 3 новых API-функции, я руководствовался следующими соображениями:

1. Колибри - не Линукс: здесь легче изменить ядро, чем довести до ума новый драйвер.

2. Системный сервис - он на то и системный, чтобы сидеть в составе кернела, а не в примочках. "Ядерные" модули в монолитной ОСи смотрятся криво.

3. Механизм системных вызовов гораздо надежнее и эффективнее, чем еще один IOCTL-канал через ж.драйвер.

4. Система однозначно предоставляет пользователю не более одного канала MMIO, и только для общения с конкретно указанным при компиляции устройством. А если сервис реализовать через драйвер - тогда юзер сможет сдуру понамаппить сколько угодно и каких угодно устройств, в любой комбинации. ИМХО первый вариант гораздо лучше застрахован от случайного доступа к чужому и системному железу.

5. Вредитель через MMIO не полезет - в распоряжении злоумышленника есть тысяча гораздо более удобных системных дыр.

6. С тезисом о том, что пользовательский доступ к "железной" памяти устройств "не является необходимым", я категорически не согласен. Нужно много новых драйверов, хороших и разных. А как довести до ума драйвер USB без отладчика? SATA? Независимый (от BIOS) энумератор устройств, конфигуратор PCIe, хотплаг? Без uMMIO у нас не будет никаких шансов на их скорую реализацию.

7. Если полноценная desktop-KOS - дело отдаленного будущего, а для netbook-KOS свет клином сошелся на графическом браузере, то embedded-KOS уже не за горами. Для многих приложений (АСУ, системы сбора данных и обработки сигналов) отдельный системный драйвер и не нужен вовсе - там приложение должно напрямую рулить железом, а система призвана лишь обеспечивать ему вспомогательный сервис и удобный аппаратный канал.

_________________
Узкий специалист подобен флюсу: полнота его - односторонняя.
Козьма Прутков


Top
   
 Post subject: Re: User-accessible MMIO
PostPosted: Sun Jan 03, 2010 3:32 pm 
Offline

Joined: Wed Mar 26, 2008 12:44 pm
Posts: 225
art_zh wrote:
4. Система однозначно предоставляет пользователю не более одного канала MMIO, и только для общения с конкретно указанным при компиляции устройством. А если сервис реализовать через драйвер - тогда юзер сможет сдуру понамаппить сколько угодно и каких угодно устройств, в любой комбинации. ИМХО первый вариант гораздо лучше застрахован от случайного доступа к чужому и системному железу.


ИМХО, можно и в драйвере предусмотреть ту-же самую глобальную переменную, хранящую конкретное устройство, и на мой взгляд, лучше было бы позволить инициализировать эту переменную, но только один раз. На мой взгляд, вероятность ошибиться при установке этой переменной в исходном коде ядра и при установке её в исходном коде вызова функции инициализации драйвера в тестовом приложении одинаковая.

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


Top
   
 Post subject: Re: User-accessible MMIO
PostPosted: Mon Jan 04, 2010 3:08 am 
Offline
Kernel Developer
User avatar

Joined: Mon Nov 28, 2005 8:00 pm
Posts: 1601
Преобразовал переменную mmio_pci_addr типа word (кстати, помещать инициализированную переменную после неинициализированных было не очень хорошей идеей) в константу времени компиляции; по умолчанию константа не определена и соответствующий код при компиляции вообще не включается в бинарник (не то чтобы его там было много, но раз он всё равно неактивен...).
P.S. Перед заливкой чего бы то ни было на svn желательно всё же проверять это хотя бы на компилябельность. У меня есть и более интересные занятия, нежели при подготовке ночной сборки выяснять, почему pcidev вообще перестал компилироваться.
tsdima wrote:
каждый раз, обновляясь с SVN я должен буду не забыть установить эту переменную в коде ядра.

Вообще-то при обновлении по svn up (aka svn update) все локальные изменения сохраняются, так что установить значение в локальной копии репозитория достаточно один раз.

_________________
Ушёл к умным, знающим и культурным людям.


Top
   
 Post subject: Re: User-accessible MMIO
PostPosted: Mon Jan 04, 2010 3:54 am 
Offline
Kernel Developer
User avatar

Joined: Fri Aug 14, 2009 1:46 am
Posts: 1351
diamond wrote:
Преобразовал переменную mmio_pci_addr типа word (кстати, помещать инициализированную переменную после неинициализированных было не очень хорошей идеей) в константу времени компиляции; по умолчанию константа не определена и соответствующий код при компиляции вообще не включается в бинарник (не то чтобы его там было много, но раз он всё равно неактивен...).

...а я в это же время перемещал mmio_pci_addr в "более подходящее место". В результате - коллизия версий, час на расшивку и 2 лишние закачки.
Условная компиляция системных функций? я бы ни за что на такое не решился... а с другой стороны, почему бы и нет?

diamond wrote:
P.S. Перед заливкой чего бы то ни было на svn желательно всё же проверять это хотя бы на компилябельность. У меня есть и более интересные занятия, нежели при подготовке ночной сборки выяснять, почему pcidev вообще перестал компилироваться.

Тут моя запарка, виноват.

tsdima wrote:
Неудобство в следующем: каждый раз, обновляясь с SVN я должен буду не забыть установить эту переменную в коде ядра. Хорошо, если она одна, но если мы и дальше будем применять такую тактику, то перед компиляцией нужно будет делать нечто аналогичное "конфигурации перед компиляцией" в линухе.

config.h - не самое худшее из того, что есть в Линуксе. Мы к этому тоже когда-то обязательно придем.


Top
   
 Post subject: Re: User-accessible MMIO
PostPosted: Thu Jan 14, 2010 3:29 pm 
Offline
Kernel Developer
User avatar

Joined: Fri Aug 14, 2009 1:46 am
Posts: 1351
Начиная с Rev.1370 сервис работает стабильно. Проверял на 4 разных машинах и на разных PCI-картах.
Для включения - раскомментировать константу mmio_pci_addr в самом начале bus/pci/pci32.inc и установить реальный PCI-адрес тестируемого утстройства.
Исправил пару багов в PciDev.asm и добавил чтение ROM-блока (правда, пока что не нашел ни одной коммерческой карты, в которой ROM был бы открыт для чтения...)


Attachments:
CAP1.gif
CAP1.gif [ 17.23 KiB | Viewed 3408 times ]

_________________
Узкий специалист подобен флюсу: полнота его - односторонняя.
Козьма Прутков
Top
   
Display posts from previous:  Sort by  
Post new topic  Reply to topic  [ 24 posts ]  Go to page Previous 1 2

All times are UTC+03:00


Who is online

Users browsing this forum: No registered users and 0 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Limited