Теорія операційної системи

:: Меню ::

Головна
Представлення даних в обчислювальних системах
Машинні мови
Завантаження програм
Управління оперативною пам'яттю
Сегментна і сторінкова віртуальна пам'ять
Комп'ютер і зовнішні події
Паралелізм з точки зору програміста
Реалізація багатозадачності на однопроцесорних комп'ютерах  
Зовнішні пристрої
Драйвери зовнішніх пристроїв
Файлові системи
Безпека
Огляд архітектури сучасних ОС

:: Друзі ::

Карта сайту
 

:: Статистика ::

 

 

 

 

 

аренда автомобилей прага от 4 Поиск авто на KAYAK в России

Windows Nt/2000/xp

Напрацювання Microsoft no Os/2 New Technology були в 1993 р. випущені на ринок під назвою Windows NT. Версії 3.x і 4.0 цієї системи забезпечували сумісність з 16-розрядними додатками для Os/2 1.x в окремій підсистемі, без можливості звертатися з 16-розрядних додатків до 32-розрядним DLL і навпаки. У описуваний період з DEC в Microsoft у повному складі перейшла команда розробників ядра VMS під управлінням Д. Катери. Microsoft широко рекламував цей факт і стверджував, що Windows NT знаходиться з VMS в набагато ближчій спорідненості, ніж з Os/2 1.x. З таблиці. П.1 видно, що це твердження не дуже-то узгоджується з дійсністю.

Таблиця П.1. Порівняння Os/2 1.2, Windows NT і VMS

Os/2 1.x
Windows NT 3.x
VMS
Mногозадачность
Що витісняє
Що витісняє
Що витісняє
Ядро
Монолітне
Монолітне
Монолітне
Уведення-виведення
Асинхронний
Асинхронний -
Асинхронний
Захист пам'яті
Сегментна
Сторінкова
Сторінкова
Трирівнева
Дворівнева
Трирівнева
Збірка при завантаженні
Динамічна
Динамічна
Статична
Підкочування
Задачна
Сторінкова
Сторінкова
Пошук жертви
FIFO
FIFO
Файлова система
Без транзакцій
Журнальна
Журнальна
Програмний RAID
RAID I
RAIDO I 5
RAIDO 1
Довжина імені файлу
256
256
32+16
Версії файлів
Немає
Немає
Так
Формати файлів
Потоковий
Потоковий
Блоковий
Відносний
Індексно- послідовний
Командний процесор
cmd.exe
cmd.exe
DCL
Граф, підсистема
РМ
Win32
X Window
Ід. користувача
Вся система
Завдання
Завдання
БД облікових записів
Розподілена
Розподілена
Локальна
Мережевий протокол
Netbios/smb
Netbios/smb
Decnet

Найбільш важливі запозичення з VMS — сторінкове підкочування і ідентифікація користувача на рівні процесів — були відповіддю на насущні вимоги розвитку системи і могли бути запозичені з будь-якої ОС, адекватної часу. У останньому, таблиця. П.1 показує, що Os/2 1.x, безумовно, доводиться Windows NT набагато ближчою ріднею, ніж VMS.
Найбільш важливою запозиченою концепцією була журнальна файлова система NTFS, що є цікавим гібридом HPFS (основний ФС Os/2) і Fcs2 (основний ФС Vax/vms). Це запозичення слід визнати досить вдалим. Набагато менш вдалим було запозичення своєрідної стратегії управління робочою безліччю процесів в ОЗУ, використовуваною в VMS: розробники Microsoft усунули з цієї стратегії одне з ключових понять, квоту розміру робочої безлічі. В результаті вийшла система, практично не здатна скористатися перевагами сторінкового підкочування, бо навіть невеликий брак оперативної пам'яті приводить до різкого падіння продуктивності із-за нездатності системи збалансувати потреби додатків і дискового кеша. Ще одна ключова для розуміння архітектури Win32 концепція була позаїмствована зовсім не з VMS і навіть не з Os/2 1.x, а була, швидше за все, введена по наполегливих проханнях розробників графічних застосувань для Apple Macintosh. Йдеться про системному реєстрі (system registry) централізованій базі даних, в якій всі модулі системи, стандартні утиліти і прикладні програми зберігають все, що вважають потрібними зберегти.
Системний реєстр вперше був реалізований в Mac OS. Ця система має досить просте ядро і небагатий набір системних налаштувань, тому реєстр Mac OS в основному містить налаштування прикладних програм і в такій формі цілком терпимий. Навпаки, досить складна розрахована на багато користувачів Windows NT, що підтримує широкий спектр зовнішніх пристроїв, потребує великого об'єму конфігураційних даних для самої системи. Характер звернень до різних частин цих даних сильно розрізняється — деякі, наприклад, потрібні лише при завантаженні системи, а зміні підлягають лише при зміні апаратній конфігурації. Інші ж міняються при кожному відкритті нового вікна призначеною для користувача програмою. Відносна цінність цих даних також розрізняється дуже різко: спотворення деяких може привести до неможливості завантажити систему або до втрати користувачами доступу до неї, деякі інші можна було б і не зберігати зовсім. В світлі цього, ідея спільного "звалища", в якому міститься все на світі, — починаючи від слів, які виголошував користувач, намагаючись прибрати з екрану знамениту скріпку, і закінчуючи БД облікових записів -представляєтся авторові не дуже-то здоровою думкою.
У Windows NT цей концептуальний недолік посилюється недоліками реалізації — реєстр не має адекватних засобів резервного копіювання і відновлення (при фатальних пошкодженнях реєстру Microsoft рекомендує переустановлення системи) і фактично позбавлений засобів самоконтролю і діагностики. В усякому разі, у версії 4.0 (автор не мав випадку перевірити це на пізніших версіях системи, але судячи по тому, що виправлення цієї помилки не анонсувалося, в 2000/хр ситуація не змінилася) ОС ніколи не зменшувала об'єм реєстру, навіть після видалення великої кількості ключів.
Ще однією важливою новиною була підтримка декількох процесорів — окрім х8б перші версії Windows NT були реалізовані для RISC-процессоров MIPS і DEC Alpha, і, істотно пізніше, для POWERPC. Більшості RISC-процессоров не мають багаторівневих режимів доступу, характерних для VAX і 80286Д86, тому розробники Windows NT були вимушені відмовитися від привілейованих бібліотек (поняття, яке в тій або іншій формі було присутнє як в Os/2 1.x, так і в Vax/vms), що розділялися, і перейти до дворівневої системи привілеїв.
Розробники додатків не виявили цікавості до альтернативної апаратної архітектури, тому NT на цій архітектурі не мала великого успіху, і в 1999 р. без великого шуму була припинена підтримка Windows NT для останнього нєїнтеловського процесора, який на той час вже називався Compaq Alpha [techupdate.zdnet.com]. До того ж, поки NT була маловикористовуваною системою з бідним набором мережевих сервісів, мало хто серйозно цікавився її зломом. Це привело до посилення тиску з боку управлінців - "ось бачите, у сусідів стоїть -- і нічого", тому сервери під управлінням NT все частіше і чаші підключалися до Internet, інколи навіть без закриття яким-небудь брандмауером (треба відзначити, що firewall (брандмауер) в даному випадку мало чим може допомогти — сайт [www.microsoft.com] закритий маршрутизатором з фільтрацією пакетів "по самі вуха", і те його "упускають" кілька разів в рік). Поширення системи привело до того, що зломщики із спортивного інтересу зацікавилися нею серйозно. Першою ластівкою був випущений в 1997 р. вільно поширюваний продукт Back Orifice (дослівно — "задній прохід"), що демонстрував цілий набір способів діставання неавторизованого доступу (у тому числі і з подальшою установкою троянських програм) до систем Win32. Встановлюваний як троянська програма компонент пакету довгий час був кращим з доступних інструментів видаленого управління Win32-системамі і автор знає немало системних адміністраторів, які використовували його в своїх мережах [www.sourceforge.net bo2k]. Втім, одна ластівка весни не робить, і ще три роки користувачі Win32-chctcm жили відносно спокійно (якщо можцо вважати спокійним життям постійну боротьбу з макровірусами для MS Office, поштовими вірусами і іншими породженнями хворої фантазії). За цей час в систему додалися нові мережеві сервіси і розширилася номенклатура сервісів, що запускаються при установці ОС за умовчанням, — наприклад, в їх число попав флагманський серверний продукт, сервер ftp/http і ряд інших протоколів, IIS (Internet Information Server). Власне весна настала в серпні 2001 р. з пандемією мережевого черв'яка Code Red, який, як і черв'як Моріса, використовував декілька каналів поширення, у тому числі зриви буфера в мережевих сервісах IIS. Як і черв'як Моріса, заразивши одну з машин домена, Code Red поширювався на інші машини того ж домена простим копіюванням по мережі. Подальший розвиток подій, втім, різко відрізнявся від наслідків атаки червя Моріса: Microsoft досить швидко випустила латки (patches)що виправляли частину використовуваних вірусом помилок — проте повна кількість помилок, що залишилися в коді системи і мережевих сервісів, від цього майже не змінилося. Атаки черв'яків і полівалентних (що використовують декілька каналів поширення) вірусів, які легко долають корпоративні брандмауери (firewalls) продовжувалися впродовж всього 2001 р., демонструючи все нові і нові проблеми в системі безпеки Windows Nt/2000/xp. У опублікованому у вересні 2001 р. доповіді аналітична компанія Gartner Group рекомендувала ні за яких обставин не використовувати IIS через величезну кількість відомих і вельми песимістичні прогнози на кількість невідомих уязвімостей. До моменту написання книги прогнозувати подальший розвиток подій не представлялося можливим. Очевидно, що ситуація з безпекою Windows може лише погіршуватися — або, точніше, абсолютна нетерпимість положення справ з безпекою в Windows може ставати лише і більш очевидніша все більшому і більшому громадянству. Спроби виправити положення законодавчими заходами, наприклад, застосовуючи кримінальні покарання до розробників вірусів або забороняючи публікацію відомостей про проблеми з безпекою, навряд чи можуть змінити тенденцію. Так, покарання для розробників вірусів, хоча і морально виправдано, але навряд чи може бути ефективним, бо в більшості випадків творця практично неможливо ідентифікувати, а ідентіфіцировав — вельми складно довести його провину по стандартах судочинства демократичних країн. У свою чергу, законодавча заборона публікації відомостей про помилки, розмови про яке почалися в 2001 р., не лише абсолютно не виправданий морально, але і украй шкідливий з прагматичної точки зору, хоч би тільки тому, що зробить неможливим прийняття контрзаходів адміністраторами уразливих систем. Оптимістичний сценарій розвитку подій може полягати в тому, що користувачі почнуть масовим чином відмовлятися від вживання Windows, або Microsoft перегляне свій підхід до проектування, розробки і тестування програмного забезпечення (або що в даному випадку включає). Так або інакше, виправлення положення зажадає значних вкладень в перебудову всієї обчислювальної інфраструктури і не може пройти безболісно. Втім, історичний досвід дає авторові вельми мало підстав для оптимізму.

 

:: Реклама ::

 

:: Посилання ::


 

 

 


Copyright © Kivik, 2017