
- •Операційні системи
- •1.Принципи побудови ос. Теоретичні основи процесу
- •2. Властивості та класифікація процесів. Життєвий цикл процесу.
- •Арі процесів. Функція fork. Функція exit.
- •Сигнали. Функція wait, waitpid. Функція exec.
- •Ресурси ос. Визначення ресурсу. Властивості та класифікація ресурсів.
- •Концепція віртуалізації. Віртуальна машина.
- •Дисципліни розподілу ресурсів які використовуються в ос.
- •Концепція переривань Теорія переривань
- •Блокування. Сигнали. Сигнальна маска. Функція sigaction.
- •Процеси-демони. Поняття про демони. Основні демони unix. Приклад програми демону
- •Засоби, механізми і підсистеми ос. Системи керування процесами. Дворівнева система керування процесами.
- •Засоби, механізми і підсистеми ос. Рівень довгострокового планування. Схема довгострокового рівня планування.
- •Засоби, механізми і підсистеми ос. Рівень короткострокового планування. Схема рівня планування.
- •Структури даних процесів. Стан процесів у unix. Особливості планувальника unix ( Linux).
- •Дескриптори процесів.
- •Взаємодія між процесами у unix.
- •Канали. Fifo (First InFirst Out). Повідомлення (черги повідомлень).
- •Семафори. Задачі синхронізації.
- •Архітектура та основні питання побудови механізмів синхронізації
- •Семафорна техніка синхронізації та упорядкування процесів.
- •Підсистема введення/виведення системи unix. Драйвери пристроїв. Типи драйверів. Базова архітектура драйверів
- •Файлова підсистема ос. Суперблок. Індексні дескриптори. Імена файлів. Каталоги.
- •Побудова підсистем ядра мультипрограмних ос. Організація віртуальної оп. Основні поняття та принципи віртуалізації пам’яті.
- •Принципи керування пам’яттю у unix. Віртуальна та фізична пам’ять. Сегменти. Сторінковий механізм.
- •Адресний простір процесів. Керування пам’яттю процесу.
- •Планування виконання процесі. Обробка переривань таймеру. Відкладений виклик. Аларми. Контекст процесу.
- •Архітектура віртуальної фс. Віртуальні індексні дескриптори. Монтування фс.
- •Архітектура віртуальної фс. Трансляції імен. Доступ до фс. Файлова таблиця.
- •Архітектура віртуальної фс. Блокування доступу до файлу.
Архітектура та основні питання побудови механізмів синхронізації
Семафорна техніка синхронізації та упорядкування процесів.
Підсистема введення/виведення системи unix. Драйвери пристроїв. Типи драйверів. Базова архітектура драйверів
Підсистема введення-виведення виконує запити файлової системи, взаємодіючи з драйверами пристроїв. В UNIX розрізняють два типи пристроїв: символьні (наприклад, принтер) і блокові (наприклад, жорсткий жиск).
Драйвери — це особливий тип комп'ютерних програм, розроблених для коректної взаємодії з пристроями. Вони представляють інтерфейс для взаємодії з пристроєм через певну шину комп'ютера, до котрої даний пристрій під'єднано, за допомогою ряду команд що відправляють та отримують дані з пристрою. Ці програми залежні як від пристрою так і від операційної системи, тобто кожен пристрій потребує свого драйвера під кожну ОС.
Ключовим моментом проектування драйверів є абстрагування. Кожна модель пристрою (навіть якщо пристрої однакового класу) є унікальною. Новіші моделі часто працюють швидше чи продуктивніше і інакше контролюються. ОС не може знати, як контролювати кожен пристрій зараз і в майбутньому. Для вирішення цієї проблеми ОС лише задає правила поведінки класу пристроїв. Задачею драйвера є перетворення цих правил у специфічні для кожного пристрою команди керування.
Драйвери пристроїв (Device Driver) – це програма, яка безпосередньо керує будь-яким пристроєм введення/виведення або іншими ресурсами комп’ютера. Драйвери у Windows 98SE забезпечують функціональність багатозадачного середовища, яке має дати можливість одночасного доступу кількох додатків до одного зовнішнього пристрою чи ресурсу. Завдання віртуалізування ресурсів в ОС Windows 98SE розв’язувається саме драйверами віртуальних пристроїв. Файлам з драйверами віртуальних пристроїв надається розширення VxD. Замість “х” можна підставити: Т-таймер, отримаємо VTD – драйвер віртуального таймера, р – VРD – драйвер віртуального принтера тощо.
Драйвери є динамічні, тобто можуть завантажуватись до оперативної пам’яті в разі необхідності й вилучатися, якщо не є потрібні. Частка драйверів є статичними: обов’язково завантажуються разом з ОС і залишаються в оперативній пам’яті постійно. Драйвери VxD мають такі переваги: функціонують в захищеному режимі процесора, використовують усі можливості 32-розрядних процесорів й забезпечують високу продуктивність ОС.
При роботі в MS-DOS використовують драйвери реального часу, тобто не динамічні.
Для розробляння нових драйверів у разі необхідності працювати з нестандартними зовнішніми пристроями використовується двокомпонентна модель:
універсальний драйвер, який зреалізовує функції керування пристроями певного класу (принтери, модеми, монітори);
міні-драйвери, що враховують особливості конкретного пристрою.
Базова архітектура драйверів. Символьні пристрої.
У книзі крім базових основ написання драйверів, які є невід'ємними компонентами засобів захисту інформації, представлена загальна і мережева архітектура ОС Windows NT. Опис архітектури необхідно для визначення наданих можливостей з реалізації та встраиванию засобів захисту мережевої інформації, а також для порівняння можливих способів реалізації захисту та визначення найбільш бажаних способів. Дослідження архітектури ОС Windows NT дозволяє визначити не тільки те, як і куди можна вбудувати засіб захисту, але і те, як цьому засобу надати найбільші можливості з боку операційної системи, оскільки від цього залежить вирішення конкретних завдань по захисту, які воно зможе реалізувати.
Володіння архітектури ОС і драйверів стосовно сфері захисту інформації необхідно з різних точок зору:
• З точки зору засобів захисту інформації, в тому числі і нестандартних (чи не згаданих у документації до ОС).
• З точки зору подолання засобів захисту.
Припустимо, нам необхідно розробити засіб захисту. Його типова структура на даний момент виглядає приблизно так:
Реалізація майже всіх перерахованих елементів системи захисту для ОС NT можлива тільки із застосуванням драйверів:
• Захист локальних даних - або драйвер шифрувальної файлової системи, або драйвер-фільтр для прозорого шифрування, або перехоплення викликів системних сервісів.
• Захист мережевих даних - драйвер протоколу, NDIS-драйвер проміжного рівня, власна мережева служба, фільтр стандартної мережної служби (такі служби реалізовані як файлові системи), перехоплення викликів системних сервісів.
• Виявлення порушника для всіх вищенаведених варіантів - аналіз подій, реєстрація в журналі, запит на підтвердження підозрілих дій.
Для спеціалізованого обладнання повинні бути розроблені драйвери для інтеграції в цю схему.
Залежно від конкретної постановки задачі повинен бути обраний найбільш відповідний спосіб її вирішення. Однієї відповіді на всі випадки життя бути не може, так як два основних критерії вибору рішення:
• критерій максимальної простоти реалізації;
• критерій максимальної універсальності суперечать один одному: чим більш універсальним може бути варіант реалізації, тим складніше його реалізація і навпаки.
Як приклад можна привести завдання реалізації захисту мережевого трафіку. Найбільш універсальним (з точки зору повноти контрольованого трафіку) і, на перший погляд, простим в цьому випадку буде NDIS-драйвер проміжного рівня. Однак, у міру ускладнення системи та наближення її до комерційної реалізації, будуть виникати більш серйозні проблеми. Наприклад, така система повинна знати формати всіх протоколів в системі, в тому числі і тих, які в даний момент навіть не створені.
При виборі способу реалізації системи життєво важливим може бути також питання документованості цього способу, при цьому треба враховувати, що велика частина ОС NT не документована.
Драйвери ядра можна розбити на 2 великі класи: драйвери апаратних пристроїв і драйверів віртуальних пристроїв:
1. 1. Архітектура NT виключає використання пристрою, якщо для нього немає драйвера. Прикладного ПЗ доступ до апаратури заборонений. Тому найочевиднішим прикладом драйверів є драйвер апаратного пристрою, що надає прикладним програмам інтерфейс доступу до пристрою. В області захисту інформації завдання написання таких драйверів вельми актуальна.
2. Драйвер віртуального пристрою не працює з яким або спеціалізованим апаратним пристроєм, однак, надає прикладним програмам такі можливості по роботі зі стандартними ресурсами комп'ютера і ОС (процесор, пам'ять, порти, регістри, службові структури ОС), які без драйвера були б недоступні.
Що конкретно можна зробити за допомогою драйвера віртуального пристрою?
Як буде видно з наступних розділів, системна архітектура NT представляє собою набір модулів, пов'язаних один з одним стандартними, але далеко не завжди документовані інтерфейсами. Завдяки цим інтерфейсам можна робити як заміну стандартних модулів на власні, так і вставляти нові модулі в «розрив» зв'язків між старими. Такий пристрій ОС дозволяє розробляти нові модулі (драйвери) для різних цілей:
• «прозора», тобто невидима для прикладних програм, обробка даних, наприклад, шифрування і компресія даних на диску або в комп'ютерній мережі;
• розширення набору наданих ОС сервісів;
• «прозоре» сканування на наявність вірусів;
• написання вірусів і закладок;
• засоби збору статистики про події для різних компонентів системи.
Слід мати на увазі, що крім загальних правил розробки та взаємодії
драйверів існують спеціальні правила для особливих типів драйверів. Як приклад можна навести драйвери файлової системи FSD та мережеві драйвери - архітектура NDIS і TDI.
Необхідно зупинитися на стані вивченості даної області. Керівництв з розробки драйверів для ОС Windows NT, виданих російською мовою, а також інформації в галузі архітектури ОС Windows NT набагато менше, ніж для звичайного програмування. У зарубіжній літературі також дуже мало книг, присвячених даній тематиці. Що стосується підмножини цієї тематики - мережевий архітектури, мережевих інтерфейсів і мережевих драйверів, то відповідної спеціалізованої літератури практично немає. Основним джерелом інформації є документація Microsoft Windows NT Device Driver Kit Version 4.0 і документація Microsoft Platform Software Development Kit.
Перераховані джерела подають інформацію про загальну і мережевий архітектурі, але ніяк не зачіпають питання реалізації засобів захисту мережевої інформації.
При читанні цієї книги настійно рекомендується мати під рукою:
• довідник по Visual C + +;
• MSDN library;
• довідник по командах асемблера.
Символьні пристрої являють собою значну частину періфе ¬ рийного обладнання системи, включаючи термінали, маніпулятори (наприклад, миша), клавіатуру і локальні принтери. Основна відмінність цих пристроїв від блокових полягає в тому, що вони, як правило, передають невеликі обсяги даних. Обмін даними з символьними пристроями відбувається безпосередньо через драйвер, минаючи буферний кеш. При цьому дані зазвичай копіюються в драйвер з адресного простору процесу, запит операцію введення / виведення.
Якщо процес зробив системний виклик введення / виведення, наприклад, read (2) або write (2) зі спеціальним файлом символьного пристрою, запит направляється у файлову підсистему. Оскільки доступ до пристрою обслуговується файлової системою specfs, розглянутої раніше, у відповідь на виконання системного виклику процесу ядро виконує виклик функції spec_read () або spec_write () відповідно для read (2) або write (2). Дії функцій spec__read {) і spec_write () схожі. Обидві перевіряють тип vnode і визначають, що пристрій є символьним. Після цього за допомогою комутатора ядро вибирає відповідну точку входу драйвера, використовуючи старший номер, що зберігається в полі v_rdev vnode, і викликає цю функцію (відповідно xxread () або xxwrite ()), передаючи їй в якості параметрів старший і молодший номери, ряд додаткових параметрів , що залежать від конкретного виклику, а також явно чи неявно адресує область копіювання даних в адресному просторі процесса3.