Чи вводить операційна система власний машинний код під час відкриття програми?

Я вивчаю процесори і знаю, як він читає програму з пам'яті та виконує її вказівки. Я також розумію, що ОС розділяє програми в процесах, а потім чергує їх між собою так швидко, що ви думаєте, що вони працюють одночасно, але насправді кожна програма працює окремо в процесорі. Але якщо ОС також є купою коду, що працює в процесорі, то як він може управляти процесами?

Я думав, і єдине пояснення, про яке я міг би подумати, це: коли ОС завантажує програму із зовнішньої пам’яті в оперативну пам’ять, вона додає власні вказівки в середині вихідних інструкцій програми, тож програма виконується, програма може зателефонувати в ОС і зробити деякі речі. Я вважаю, що існує вказівка, що ОС додасть до програми, що дозволить центральному процесорові деякий час повертатися до коду ОС. А також я вважаю, що коли ОС завантажує програму, вона перевіряє, чи є якісь заборонені вказівки (які могли б перейти на заборонені адреси в пам'яті) і усуває потім.

Чи я думаю про річ? Я не студент CS, а насправді студент з математики. Якщо можливо, я хотів би отримати хорошу книгу про це, тому що я не знайшов нікого, який би пояснював, як ОС може керувати процесом, якщо ОС також є купою коду, що працює в центральному процесорі, і він не може працювати при цьому час програми. Книги говорять лише про те, що ОС може керувати речами, а тепер як.

Ні. Операційна система не возиться з кодом програми, вводячи в неї новий код. Це матиме ряд недоліків.

1. Це буде трудомістким, оскільки ОС повинна буде переглядати весь виконуваний файл, вносячи його зміни. Зазвичай частина виконуваного файлу завантажується лише за потреби. Крім того, вставка коштує дорого, оскільки вам доведеться перемістити безліч речей.

2. Через нерозбірливість проблеми зупинки неможливо знати, куди потрібно вставити вказівки "Перейти назад до ОС". Наприклад, якщо код включає щось на кшталт while (true) {i++;}, вам обов'язково потрібно вставити гачок всередині цього циклу, але умова в циклі ( true, тут) може бути довільно складною, тому ви не можете вирішити, наскільки він циклічний. З іншого боку, було б дуже неефективно вставляти гачки у кожен цикл: наприклад, вистрибування назад до ОС під час for (i=0; i<3; i++) {j=j+i;}дуже уповільнить процес. І, з тієї ж причини, ви не можете виявити короткі петлі, щоб залишити їх у спокої.

3. Через невирішеність проблеми зупинки неможливо дізнатися, чи змінили код зміни змісту програми. Наприклад, припустимо, що ви використовуєте в своїй програмі C покажчики функцій. Введення нового коду перемістить розташування функцій, тож, коли ви зателефонували за ним через вказівник, ви перескочили б у неправильне місце. Якби програміст був достатньо хворий для використання обчислених стрибків, вони теж не зможуть.

4. Це зіграло б веселе пекло з будь-якою антивірусною системою, оскільки воно також змінило б код вірусу і примрушило всі ваші контрольні суми.

Ви можете подолати проблему, що зупиняється, імітуючи код і вставляючи гачки в будь-який цикл, який виконується більше певної фіксованої кількості разів. Однак це вимагало б надзвичайно дорогого моделювання всієї програми до того, як її дозволили виконати.

Насправді, якби ви хотіли вставити код, компілятор був би природним місцем для цього. Таким чином, вам доведеться це зробити лише один раз, але це все одно не вийде з другої та третьої причин, наведених вище. (І хтось може написати компілятор, який не програвав.)

Існує три основні способи відновлення управління ОС процесами.

1. У кооперативних (або не випереджаючих) системах є yieldфункція, яку може викликати процес, щоб повернути управління ОС. Звичайно, якщо це ваш єдиний механізм, ви покладаєтесь на процеси, які добре поводяться, і процес, який не поступається, буде зависати процесором, поки він не припиниться.

2. Щоб уникнути цієї проблеми, використовується переривання таймера. Процесори дозволяють ОС реєструвати зворотні дзвінки для різних типів переривань, які реалізує процесор. ОС використовує цей механізм для реєстрації зворотного дзвінка для переривання таймера, який періодично запускається, що дозволяє виконувати власний код.

3. Кожен раз, коли процес намагається прочитати файл або взаємодіяти з обладнанням будь-яким іншим способом, він просить ОС зробити роботу над цим. Коли ОС вимагає зробити щось за допомогою процесу, він може прийняти рішення про припинення цього процесу та почати запускати інший. Це може здатися трохи макіавельським, але це правильно зробити: введення / виведення диска повільне, тому ви можете також пустити процес B в той час, як процес A чекає, коли прядильні грудочки металу перемістяться в потрібне місце. Мережевий введення / виведення ще повільніше. Клавіатурний ввод / вивід є льодовиковим, оскільки люди не є гігагерцевими істотами.

Незважаючи на те, що відповідь Девіда Ріхербі хороша, він виглядає таким чином, як сучасні операційні системи зупиняють існуючі програми. Моя відповідь повинна бути точною для архітектури x86 або x86_64, яка є єдиною, яка зазвичай використовується для настільних ПК та ноутбуків. Інші архітектури повинні мати подібні методи досягнення цього.

Коли операційна система запускається, вона встановлює таблицю переривань. Кожен запис таблиці вказує на біт коду всередині операційної системи. Коли трапляються переривання, якими керує процесор, він переглядає цю таблицю і викликає код. Існують різні переривання, такі як ділення на нуль, недійсний код та деякі визначені операційною системою.

Ось як користувальницький процес спілкується з ядром, наприклад, якщо він хоче читати / записувати на диск або щось інше, яким керує ядро ​​операційної системи. Операційна система також встановить таймер, який викликає переривання, коли він закінчується, тому запущений код насильно змінюється з програми користувача на ядро ​​операційної системи, і ядро ​​може робити інші речі, такі як чергування інших програм для запуску.

З пам’яті, коли це відбувається, ядро ​​операційної системи має зберегти те, де був код, і коли ядро ​​закінчило робити те, що для цього потрібно, відновлює попередній стан програми. Таким чином, програма навіть не знає, що вона була перервана.

Процес не може змінити таблицю переривань з двох причин. Перша полягає в тому, що вона працює в захищеному середовищі, тому якщо вона намагається викликати певний захищений код складання, процесор спровокує інше переривання. Друга причина - віртуальна пам'ять. Розташування таблиці переривань становить від 0x0 до 0x3FF у реальній пам'яті, але при користувацьких процесах це розташування зазвичай не відображається, а спроба читання незробленої пам'яті призведе до іншого переривання, тому без захищеної функції та можливості запису на реальну оперативну пам'ять , користувацький процес не може його змінити.

Ядро ОС отримує контроль від запущеного процесу завдяки оброблювачам переривань тактового процесора, а не шляхом введення коду в процес.

Ви повинні прочитати про переривання, щоб отримати більше роз'яснень щодо того, як вони працюють і як ядра ОС обробляють їх та реалізують різні функції.

Там є метод , подібний до того , що ви описали: кооперативну багатозадачність . В ОС не вставляються інструкції, але кожна програма повинна бути написана для виклику функцій ОС, які можуть вибрати інший із спільних процесів. Це має недоліки, які ви описуєте: одне збої програми виймає всю систему. Вікна до 3.0 включаючи, працювали так; 3.0 в "захищеному режимі" і вище не було.

Попереджувальна багатозадачність (звичайний вид в ці дні) покладається на зовнішнє джерело переривань. Перерви перекривають нормальний потік управління і зазвичай зберігають регістри десь, тож ЦП може зробити щось інше, а потім прозоро відновити програму. Звичайно, операційна система може змінити реєстр "коли ви залишаєте переривання резюме тут", тому вона відновиться в іншому процесі.

(Деякі системи виконують перезапис інструкцій обмеженим чином щодо завантаження програми, званого "thunking", і процесор Transmeta динамічно перекомпілюється у свій власний набір інструкцій)

Багатозадачність не вимагає нічого, як введення коду. В такій операційній системі, як Windows, є компонент коду операційної системи, який називається планувальником, який спирається на апаратне переривання, ініційоване апаратним таймером. Це використовується операційною системою для перемикання між різними програмами і самою собою, завдяки чому все це здається, що наше людське сприйняття відбувається одночасно.

В основному, операційна система програмує апаратний таймер, щоб вимикатись так часто ... можливо, 100 разів на секунду. Коли таймер вимикається, він генерує апаратне переривання - сигнал, який повідомляє процесору припинити, що він робить, зберегти його стан на стеці, змінити режим на щось більш привілейоване і виконати код, який він знайде в спеціально призначеному місце в пам’яті. Цей код є частиною планувальника, який вирішує, що робити далі. Можливо, відновиться якийсь інший процес, і в цьому випадку йому доведеться виконати те, що відомо як "контекстний перемикач" - замінивши всю його поточний стан (включаючи таблиці віртуальної пам'яті) на інший процес. Повертаючись до процесу, він повинен відновити весь контекст цього процесу,

«Спеціально відведене» місце в пам’яті не повинно знати нічого, крім операційної системи. Реалізація відрізняється, але суть полягає в тому, що ЦП реагуватиме на різні переривання, здійснюючи пошук таблиці; розташування таблиці знаходиться на певному місці в пам'яті (визначається апаратною конструкцією процесора), вміст таблиці встановлюється операційною системою (як правило, під час завантаження), і "тип" переривання визначатиме, який запис в таблиці слід використовувати як "звичайний режим переривання".

Ніщо з цього не передбачає "введення коду" ... воно засноване на коді, що міститься в операційній системі у взаємодії з апаратними функціями ЦП та його підтримуючої схеми.

Я думаю, що найближчим прикладом реального світу до того, що ви описуєте, є одна з методик, що використовуються VMware , повна віртуалізація з використанням бінарного перекладу .

VMware діє як шар під однією або декількома одночасно виконаними операційними системами на одному і тому ж апаратному забезпеченні.

Більшість інструкцій, що виконуються (наприклад, у звичайних додатках), можна віртуалізувати за допомогою апаратного забезпечення, але саме ядро ​​ОС використовує інструкції, які не можна віртуалізувати, тому що якщо машинний код здогадки ОС був виконаний немодифікованим, він "вибухне" "управління хостом VMware. Наприклад, гостьовій ОС потрібно запустити в найбільш привілейоване захисне кільце і встановити таблицю переривань. Якби це було дозволено, VMware втратив би контроль над обладнанням.

VMware переробляє ці інструкції в коді ОС перед її виконанням, замінюючи їх стрибками в код VMware, що імітує потрібний ефект.

Тож ця техніка дещо аналогічна тому, що ви описуєте.

Є різні випадки, коли операційна система може "вводити код" у програму. На основі 68000 версій системи Apple Macintosh створена таблиця всіх сегментів входу сегмента (розташована безпосередньо перед статичними глобальними змінними, IIRC). Коли програма запускається, кожен запис у таблиці складається з інструкції щодо пастки, за якою слідує номер сегмента та зміщення в сегмент. Якщо пастка виконана, система перегляне слова після інструкції пастки, щоб побачити, який сегмент і зсув потрібен, завантажте сегмент (якщо його ще немає), додайте стартову адресу сегмента до зміщення та потім замініть пастку стрибком до цієї щойно обчисленої адреси.

На старшому програмному забезпеченні ПК, хоча це не було технічно зроблено "ОС", звичайно, щоб код був побудований з інструкціями щодо пастки замість інструкцій з математики копроцесора. Якщо не було встановлено математичного співпроцесора, обробник пастки буде імітувати його. Якщо був встановлений копроцесор, перший раз, коли буде взято пастку, обробник замінить інструкцію пастки на інструкцію копроцесора; майбутні виконання цього ж коду будуть використовувати безпосередньо інструкцію співпроцесора.