МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ Дніпровський національний університет імені Олеся Гончара Факультет фізики, електроніки та комп’ютерних систем Кафедра комп’ютерних наук та інформаційних технологій Реферат з навчальної дисципліни "Проєктування систем реального часу” на тему: «Принципи сучасних ОСРЧ. Azure ThreadX» студента 5 курсу групи КС-20м-1 122 “ Комп'ютерні науки та інформаційні технології” Петрук Д.В. _________________________ (підпис студента) Перевірив доц. Вовк С.М. Кількість балів ___________________ Національна шкала _______________ Оцінка ECTS_____________________ Дніпро – 2021 2 ВСТУП Система реального часу (СРЧ) - це система, правильність функціонування якої залежить не тільки від логічної коректності обчислень, але і від часу, за який ці обчислення проводяться. Для подій, що відбуваються в такій системі, важливо час, коли ці події відбуваються, і їх логічна коректність. Система працює в реальному часі, якщо її швидкодію адекватно швидкості протікання фізичних процесів на об'єктах контролю або управління (маються на увазі процеси, безпосередньо пов'язані з функціями, виконуваними конкретною системою реального часу). Система управління повинна зібрати дані, провести обробку інформації за заданими алгоритмами і видати керуючий вплив за такий проміжок часу, який забезпечує успішне виконання поставлених завдань. 3 Зміст Вступ .................................................................................................................. 2 1. ОГЛЯД ОСОБЛИВОСТЕЙ СРЧ ............................................................ 4 1.1 Поняття операційної системи реального часу .................................... 4 1.2 Основні вимоги та характеристики СРЧ ............................................. 6 1.3 Способи використання СРЧ ................................................................. 7 1.4 Вимоги, що пред'являються ОС при проектуванні ОСРЧ ................ 8 2. ОГЛЯД Azure RTOS ThreadX ................................................................ 12 2.1 Загальний опис ThreadX ..................................................................... 12 2.2 Особливості ОСРЧ ThreadX .............................................................. 12 2.3 Використання пам'яті у ThreadX ........................................................ 14 2.4 Підтримка архітектури ........................................................................... 14 2.5 Симетрична і асиметрична багатопроцесорна обробка ................... 16 2.6 Інструмент віртуалізації Tracealyzer ...................................................... 17 2.7 Використання Tracealyzer ................................................................... 19 2.8 Уразливості Azure ThreadX .................................................................... 21 ВИСНОВКИ .................................................................................................... 24 СПИСОК ЛІТЕРАТУРИ ................................................................................ 25 4 1. ОГЛЯД ОСОБЛИВОСТЕЙ СРЧ 1.1 Що таке система реального часу Останнім часом все частіше доводиться стикатися з завданнями, які вимагають управління складними процесами або устаткуванням за допомогою ЕОМ. При цьому всі події в цих процесах відбуваються тоді, коли вони відбуваються. Комп'ютер може виконувати лише кінцеве число операцій в кінцевий час, тому виникає питання: а чи встигне комп'ютер з потрібною швидкістю обрахувати ситуацію і видати конкретні керуючі дії, які були б адекватні саме в певний момент часу. На мій погляд, проблеми подібного роду виникли через використання дуже великих швидкостей в сучасному виробництві. Ясно, що сигнали в природі поширюються з кінцевою швидкістю, швидкість роботи теж скінченна, тому миттєвих дій (викликаних деякою подією) від комп'ютера чекати принципово неможливо. Адже яким би сучасним (читай - потужним по продуктивності, тобто високою швидкістю обробки команд і операцій) комп'ютер б не був - йому фізично потрібні хоча б частки секунди, щоб виконати невелику просту групу команд, а іноді цього часу дуже багато. Таким чином, час реакції системи на деякий подія строго більше нуля. Реальні задачі допускають деякого запізнення дій, і якщо система має час реакції менше, ніж ця допустима затримка, то її справедливо називати системою реального часу. Так як в природі різні процеси протікають з різною швидкістю, одна і таж система може укладатися в задані рамки для одного процесу і не укладатися для іншого. Таким чином, про систему реального часу має сенс говорити стосовно до конкретної задачі. Наприклад, щоб побудувати залежність середньої температури повітря за день від дня тижня в якості системи реального часу зійде практично будь-який комп'ютер з практично будь. Якщо ж ми управляємо посадкою літака, де істотну роль відіграють мілісекунди, було б більш правильно уважно вибирати апаратне і програмне забезпечення. 5 Крім розглянутої задачі реагування на деякий подія, існують ще інші класи задач реального часу. Однією з поширених є завдання постійного спостереження або управління динамічним процесом, тобто коли потрібно безперервно обмінюватися сигналами із зовнішнім світом. Комп'ютер дискретна система, тому доводиться здійснювати деякі дії з деякими кінцевими проміжками часу, вважаючи, що ці малі проміжки часу зовнішній світ залишається незмінним. Якщо наша система здатна обробляти інформацію і видавати керуючі сигнали з необхідною частотою, то її можна назвати системою реального часу. Неважко зрозуміти, що цю задачу легко звести до попередньої, використовуючи як події початок чергового інтервалу часу. Час реакції повинен бути меншим за час дискретизації процесу. Таким чином, описана раніше завдання є найбільш важливим, коли мова йде про системах реального часу. Слід зазначити, що незадовільна по запізнюванню робота системи в деяких завданнях може призвести до фатальних наслідків, а в деяких не відбудеться ніяких позаштатних і небажаних ситуацій. Наприклад: якщо система вимірювання температури з наведеного вище прикладу випадково запізниться на недозволене час, то це означає, що ми просто змінили вибірку точок знімання температури, і все одно отримаємо правильний результат, якщо ж на секунду випадково затримається автомат заходу на посадку в пасажирському літаку при раптовому пориві вітру, літак може не потрапити на смугу і десятки людей загинуть. Таким чином, слід ділити системи на системи жорсткого і м'якого реального часу. Системою жорсткого реального часу називається система, де нездатність забезпечити реакцію на будь-які події в заданий час є відмовою і веде до неможливості вирішення поставленого завдання. Час реакції в системах жорсткого реального часу повинно бути мінімальним. Більшість систем жорсткого реального часу є системами контролю і управління. Такі СРЧ складні в реалізації, так як до них пред'являються особливі вимоги в питаннях безпеки. 6 Точного визначення м'якого реального часу не існує, тому можна віднести сюди все СРЧ, не підпадають під категорію жорстких. Так, система м'якого реального часу може не встигати все робити в заданий час, тому виникає проблема визначення критеріїв успішності (нормальності) її функціонування. Крім того, СРЧ можна поділити на спеціалізовані і універсальні. o Спеціалізована СРЧ - система, де конкретні тимчасові вимоги спочатку визначені. Така система повинна бути спеціально спроектована для задоволення цих вимог. o Універсальна СРЧ повинна вміти виконувати довільні (заздалегідь невизначені) тимчасові завдання без застосування спеціальної техніки. Розробка таких систем є найбільш складним завданням, хоча зазвичай, вимоги, що пред'являються до таких систем, м'якше, ніж вимоги до спеціалізованим системам. 1.2 Основні вимоги та характеристики СРЧ СРЧ повинні реагувати на різні типи внутрішніх і зовнішніх подій (періодичних та неперіодичних). Необхідно зазначити, що приналежність до класу СРЧ ніяк не пов'язана з її швидкодією. Вихідні вимоги до часу реакції системи та інших параметрів визначаються або технічним завданням на систему, або просто логікою її функціонування. Інтуїтивно зрозуміло, що швидкодія СРЧ має бути тим більше, чим більше швидкість протікання процесів на об'єкті контролю і управління. Основні вимоги до СРЧ: 7 o можливість паралельного виконання декількох завдань; o передбачуваність; o важливо максимальне (не середнє) час відгуку на подію; o особливі вимоги в питаннях безпеки; o можливість безвідмовної роботи протягом тривалого часу. Загальні характеристики СРЧ: o великі і складні системи; o розподілені системи; o жорстке взаємодія з апаратурою; o виконання завдань залежить від часу; 1.3 Способи використання СРЧ Прикладом використання СРЧ можуть служити такі системи VxWorks, OS9 і т. п. Необхідно зазначити, що такі системи дуже дорогі. Наприклад, вартість повного пакету ОС VxWorks (Tornado 1.0) у 2002 році становила близько 15 000 доларів США. Втім, з роками така система значно дешевшає сьогодні її вартість становить близько 10 000 доларів (Tornado версії 2.0 і вище - повна вартість залежить від вибраних компонентів). Для більш детального розгляду можливостей ОСРЧ представлені орієнтовні цифри, дає уявлення про порядок часу реакції і відповідних операційних системах. Дана таблиця сформована на підставі експериментальних даних, отриманих на базі обчислювальних комплексів, побудованих на основі процесорів Intel 80486DX. Безумовно, даний процесор на сьогоднішній день є застарілим, але можна зробити висновки про рівень реакції на зовнішні події різних систем. 8 Часові рамки ОСРЧ досить жорсткі. Серед сучасних операційних систем є клас продуктів, розроблених спеціально для побудови систем жорсткого реального часу - VxWorks, OS9, QNX, LynxOS, OSE та інші. Ці системи містять необхідний набір інструментів, і в деяких випадках є єдиним вибором - на нього доводиться йти, незважаючи на витрати. Однак досить часто вимоги до реального часу (повна передбачуваність часу реакції) стають менш жорсткими, наприклад, необхідно домогтися тільки потрібної середньої продуктивності. Іноді достатньо жорстко контролювати лише одна з подій, допускаючи при цьому затримки реакцій на інші. У подібних випадках можливості вибору розширюються, і бажаних результатів можна досягти, використовуючи такі широко розповсюджені операційні системи LINUX, Windows NT, Windows CE, доповнюючи їх розширеннями реального часу (RTAI, RT LINUX, RTX). 1.4 Вимоги, що пред'являються ОС при проектуванні ОСРЧ Вимога 1. ОС повинна бути багатопоточною (multi-threaded) і переривається Як зазначалося вище, ОСРЧ повинна бути передбачуваною, що означає максимальне час виконання тієї або іншої дії, яка має бути відомо заздалегідь і має відповідати вимогам програми. Перша вимога полягає в тому, що ОС повинна бути багатопоточною за принципом абсолютного пріоритету (переривається). Планувальник повинен мати можливість перервати будь-яку нитку і надати ресурс тієї нитки, якою він більш необхідний. ОС (і апаратура) повинні також забезпечувати переривання на рівні обробки переривань. Вимога 2. Повинно існувати поняття пріоритету нитки Проблема в тому, щоб визначити, який завданні потрібно ресурс. В 9 ідеальній ситуації ОСРЧ віддає ресурс нитки або драйвера з найближчим крайнім терміном (так звані ОС, керовані тимчасовим обмеженням (deadline driven OS)). Щоб реалізувати це, ОС повинна знати час, необхідний кожній із виконуються ниток для завершення (до сих пір не існує ОС, побудованої за цим принципом, так як він занадто складний для реалізації), тому розробники ОС приймають іншу точку зору: вводиться поняття рівня пріоритету задачі, і тимчасові обмеження зводять до пріоритетів. Так як умоглядні рішення чреваті помилками, показники СРЧ при цьому знижуються. Щоб більш ефективно здійснити зазначене перетворення обмежень, проектувальник може скористатися теорією розкладів або імітаційним моделюванням, хоча і це може виявитися марним. На сьогоднішній день немає іншого рішення, тому поняття пріоритету нитки необхідно. Вимога 3. ОС повинна забезпечувати передбачувані механізми синхронізації завдань Завдання розділяють дані (ресурси) і повинні сполучатися один з одним, отже, повинні існувати механізми блокування і комунікації. Вимога 4. Повинна існувати система успадкування пріоритетів Насправді саме цей механізм синхронізації і той факт, що різні нитки використовують одне і те ж простір пам'яті, відрізняють нитки від процесів. Процеси не розділяють одне і те ж простір пам'яті. Так, наприклад, старі версії UNIX не були багатонитковими. Старий UNIX - багатозадачна ОС, де завданнями є процеси, які повідомляються через потоки (pipes) і поділювану пам'ять. Обидва ці механізму використовують файлову систему, а її поведінка непередбачувана. Комбінація пріоритету нитки і розподіл ресурсів між ними призводить до іншого явища: класичної проблеми інверсії пріоритетів. Це можна проілюструвати прикладом, де є як мінімум три нитки. Коли нитка нижчого 10 пріоритету зайняла ресурс, що розділяється з ниткою вищого пріоритету, а спочатку виконується нитка середнього пріоритету, виконання нитки вищого пріоритету буде припинено, поки не звільниться ресурс і не відпрацює нитка середнього пріоритету. У цій ситуації час, необхідний для завершення нитки вищого пріоритету, залежить від нижніх пріоритетних рівнів - це і є інверсія пріоритетів. Ясно, що в такій ситуації важко витримати обмеження на час виконання. Щоб усунути такі інверсії, ОСРЧ повинна допускати спадкування пріоритету, тобто підвищення пріоритету до рівня викликає нитки. Спадкування означає, що блокуюча ресурс нитка успадковує пріоритет блокованою нитки (справедливо лише в тому випадку, якщо заблокованих нитка має більш високий пріоритет). Іноді стверджують, що у правильно спроектованій системі така проблема не виникає. У випадку складних систем з цим не можна погодитися. Єдиний спосіб вирішення цієї проблеми полягає у збільшенні пріоритету нитки вручну перш, ніж ресурс виявиться заблокованим - це можливо у разі, коли дві нитки різних пріоритетів претендують на один ресурс. У загальному випадку рішення не існує. Вимога 5. Поведінка ОС має бути відомою Нарешті, слід розглянути часові обмеження. Час виконання системних викликів і тимчасові характеристики поведінки системи в різних обставинах повинні бути відомі розробнику, тому виробник ОСРЧ повинна призводити наступні характеристики: латентну затримку переривання (тобто час від моменту переривання до моменту запуску завдання: вона повинна бути передбачена і узгоджена з вимогами додатка. Ця величина залежить від кількості одночасно "висять" переривань; максимальний час виконання кожного системного виклику (має бути передбачуваним і незалежним від кількості об'єктів в системі); 11 максимальний час маскування переривань драйверами і ОС. системні рівні переривань; рівні переривань драйверів пристроїв, їх тимчасові характеристики і т. д. 12 2. ОГЛЯД Azure RTOS ThreadX 2.1 Загальний опис ThreadX На сьогоднішній день існує більше 100 комерційних ОСРЧ. Є безліч безкоштовних (або умовно безкоштовних) СРЧ та систем, які мають статус дослідницьких або університетських проектів. Одною с таких ОСРЧ є Azure ThreadX. ThreadX (ST EXP-RTOS) – це операційна система реального часу (RTOS) Logic Express, розроблена спеціально для вбудованих додатків. ThreadX надає розширені засоби планування, передачі повідомлень, керування перериваннями і службами обміну повідомленнями. ThreadX володіє безліччю додаткових функцій, включаючи власну архітектуру picokernel, планування Preemption-Threshold, ланцюжок подій і набір системних служб. У поєднанні з простотою використання ThreadX є ідеальним вибором для найвимогливіших вбудованих додатків. ThreadX був розгорнутий на більш ніж 1,5 мільярди рішеннях. Компанія Ренесас Технолоджі Європа оголосила про вихід операційної системи реального часу (ОСРВ) ThreadX компанії Logic Express з підтримкою сімейства мікроконтролерів SH-2A. Для пристроїв, побудованих на мікроконтролерах SuperH з модулями Ethernet і USB, спільно з ОСРЧ, пропонується файлова система FileX, мережевий стек NetX і USB стек USBX. До складу програмних продуктів також входить графічний інтерфейс користувача (GUI) професійної якості PEGX, має невеликий розмір і високу швидкість роботи. 2.2 Особливості ОСРЧ ThreadX 13 Azure ThreadX RTOS написаний мовою програмування C та має щакритий вихідний код. Ядро, на якому основана дана ОСРЧ є вбудоване ядро реального часу, мікроядро, та пікоядро(наноядро). ThreadX в основному вбудованих системах, використовують в «інтернет речах», IoT: датчики, пристрої, граничні маршрутизатори, шлюзи. З основних особливостей можна виділити наступні: підтримка всього сімейства SuperH, включаючи SH1, SH2, SH2A, SH3, SH4, SH4A і SH-DSP розумна ціна без доплат вихідний код написаний у відповідності з ANSI C прості у використанні і потужні сервіси якісна технічна підтримка абсолютні (без обмежень) Процеси, Черги Процесів, Прапори Подій, Таймери, Семафори, Виключення, Об'єднання Блоків і Байтів гнучке використання пам'яті наявність таймаутів при будь-якому зациклення розширений механізм порогу доступу мінімально можливе використання таймерів автоматична зміна розміру архітектура «picokernel», малий розмір, висока швидкість роботи малий займаний обсяг (порівнянний з 3 Кб) 14 швидке виконання (перемикання контексту за 1.8 мкс на 20 МГц, без затримок, SH3) 2.3 Використання пам'яті у ThreadX ThreadX вимагає менше пам'яті, ніж, наприклад, інші операційні системи, такі як Windows, Linux, VxWorks і QNX. Таким чином, він підходить для додатків, що можуть використовувати переваги недорогого процесора і невеликого обсягу пам'яті. Але, вибравши менше пам'яті, розробники можуть прийти до висновку, що вони обмежують код програми, які може використовувати їх система. Для вирішення цієї проблеми Logic Express тепер може включати «завантажувані модулі програми» у ThreadX. Це означає, що невелика комп'ютерна система може динамічно отримувати додаткові інструкції по мережі або з локального пристрою (флеш-карта SD, карта пам'яті USB, невеликий жорсткий диск і т. д.). Таким чином, додаткові або більш великі програми все ще можуть працювати на невеликому комп'ютері, і компанії можуть завантажувати новий або переглянутий код, не турбуючись про брак пам'яті для цільового процесора. Згідно Logic Express, модулі ThreadX являють собою набори потоків додатків, не пов'язаних з ядром ThreadX. Замість цього модулі завантажуються в цільову пам'ять і використовують служби ядра ThreadX через інтерфейс з менеджером модулів. Диспетчер модулів ThreadX - частина ядра системи запускає модуль і обробляє всі запити модулів для API-сервісів ThreadX. Хоча ThreadX має тільки одну копію диспетчера модулів, він не обмежує кількість модулів, які можуть бути одночасно завантажені, а також не обмежує кількість потоків у будь-якому модулі. 2.4 Підтримка архітектури 15 Дана ос підтримує безліч існуючих архітектур, основними з них є ARM7, ARM9, ARM11 Cortex-M, Cortex-R, Cortex-A Cortex-Axx 64-bit TrustZone ARMv8-M AndesCore RISC-V Blackfin BF5xx, BF6xx, BF7xx SHARC CM4xx Ambiqmicro Apollo MCU Cadence Xtensa і Diamond CEVA TeakLite-III Cypress PSoC, PSoC 4, PSoC 5, 6 PSoC FM0+, FM3, FM4 WICED WiFi EnSilica eSi-RISC Infineon XMC1000 XMC4000 TriCore Intel & Intel FPGA ARM (Cyclone SOC, Arria 10 SOC) NIOSII x86PM Microchip ARM (SAM) AVR32 PIC24 PIC32 Microsemi RISC-V NXP ARM (LPC, i.MX, Kinetis) 68K Coldfire PowerPC Renesas ARM (Synergy, RZ) H8/300H 16 RX SH V850 Silicon Labs EFM32 ST STM32 Synopsys ARC 600, 700 ARC EM, ARC HS Texas Instruments ARM (Tiva-C, Sitara, OMAP) C5xx C6xx Wave Computing MIPS32 4Kx, 24Kx, 34Kx, 1004K microAptiv, interAptiv, proAptiv M-Class Xilinx ARM (Zynq, Zynq UltraSCALE) MicroBlaze PowerPC 2.5 Симетрична і асиметрична багатопроцесорна обробка ThreadX доступна для багатоядерних систем в режимах Symmetric Multiprocessing (SMP) або Asymmetric Multiprocessing (AMP), надаючи розробникам максимальну гнучкість для використання ThreadX як однорідних, так і в гетерогенних системах. При використанні однорідних процесорів, таких як ARC MPCore, Xilinx Zynq і MIPS 34K і 1004K, кожен процесор виконує один і той же код з однієї копії в пам'яті. Однорідні процесори також можуть використовуватися в режимі AMP, де кожен процесор є більш незалежним і може запускати інший код з власної локальної пам'яті. Гетерогенні процесори, такі як серія TI OMAP і нова архітектура ARM big.LITTLE, не використовують режим SMP, оскільки їх процесори, як правило, не можуть виконувати однакові інструкції з однієї і тієї ж копії в пам'яті і майже завжди працюють у режимі AMP. 17 ThreadX / SMP оптимізує ефективність процесора за допомогою автоматичного балансування навантаження та / або програмно-орієнтованої прив'язки до процесора. Розробники можуть використовувати цю функцію для запуску додатків практично незалежно від декількох процесорів в системі або для явного контролю використання кожного процесора. ThreadX / SMP автоматично запускає потоки додатків на будь-якому доступному процесорі, прозоро відображаючи багатопотокову систему реального часу на многоядерную архітектуру. В режимі AMP в однорідних або гетерогенних багатоядерних системах ThreadX працює на одному або декількох процесорах, зазвичай з локальної пам'яті процесора, з окремими копіями для кожного процесора. Якщо система складається з різнорідних процесорів, то кожна копія ThreadX відрізняється, побудована для роботи на конкретній архітектурі процесора. Наприклад, від TI OMAP об'єднує ядро ARM і ядро TI DSP у неоднорідній багатоядерної системі, яка може запускати ThreadX на кожному процесорі або тільки на одному з іншого ОСРЧ на іншому. Точно так само новий Xilinx Zynq (двопроцесорна, однорідна FPGA) може запускати ThreadX на одному процесорі, а Linux - на іншому. Межпроцессорная координація забезпечується додатком з використанням поштової скриньки із загальною пам'яттю і / або з використанням MCAPI-сумісної системи зв'язку PolyCore від PolyCore Software. Це забезпечує переваги обох операційних систем, замість того, щоб намагатися розтягнути кожну з них для обробки всіх системних функцій. В режимі SMP ThreadX / SMP підтримує MPCore від ARM, MIPS 34K і 1004K й аналогові пристрої Blackfin BF561. В режимі AMP ThreadX підтримує архітектуру Xilinx Zynq dual-Cortex-A8, а також практично будь-яку гетерогенну архітектуру 2.6 Інструмент віртуалізації Tracealyzer 18 Tracealyzer for ThreadX - це складний інструмент для відстеження та візуалізації систем на базі ThreadX. Tracealyzer дає безпрецедентну уявлення про поведінку під час виконання, що прискорює налагодження, перевірку та оптимізацію продуктивності. Проблеми, які в іншому випадку можуть зажадати багатьох годин, днів або навіть тижнів, можуть бути швидко зрозуміли з допомогою Tracealyzer. Це позбавить вас від багатьох годин розчаровують проб і помилок. З Tracealyzer ви бачите, що насправді відбувається у вашій системі! Tracealyzer забезпечує сучасну візуалізацію, розроблену з 2004 року, спеціально розроблену для систем на базі RTOS провідним фахівцем в цій галузі - компанією Percepio AB, що базується в Швеції. Tracealyzer фактично розуміє значення подій RTOS і виконує розширений аналіз для поліпшення візуалізації та спрощення розуміння. Це значно полегшує висновок з даних, розуміння проблеми і перевірку рішення. На малюнку 1 представлений приклад аналізу даних. Рисунок 1 – Приклад аналізу даних 19 Tracealyzer надає більше 25 взаємопов'язаних уявлень про поведінку під час виконання, включаючи виконання завдань (потоків), переривань, взаємодій між потоками, а також подій, які ви можете реєструвати з коду програми. Tracealyzer може використовуватися паралельно з традиційним відладчиком і доповнює уявлення відладчика перспективою більш високого рівня, що ідеально підходить для розуміння проблем реального часу, коли класичного відладчика недостатньо. Tracealyzer не вимагає додаткового обладнання для відстеження, що означає, що його можна використовувати в розгорнутих системах для виявлення окремих помилок, які в іншому випадку важко відтворити. 2.7 Використання Tracealyzer Рисунок 2 – Головний екран трасування Основне уявлення трасування надає всю записану інформацію на вертикальній шкалі, фокусуючись на виконання потоків, обробників переривань і викликів ядра. Це уявлення доповнюється приблизно 25 додатковими уявленнями, що забезпечують огляди високого рівня або сфокусовані подання з різних точок зору. Події ядра, такі як виклики служб ядра і користувальницькі події відображаються у вигляді текстових міток праворуч від трасування 20 планування. Ярлики мають кольорове кодування в залежності від типу і статусу операції (червоний для блокування, зелений для відновлення, жовтий для подій тощо). Нижче-кілька прикладів інших уявлень і діалогів, які доповнюють уявлення трасування. Все більше 25 переглядів. Всі види пов'язані з основним вікном трасування або іншим відповідним видом, який дозволяє перемикати перспективи без втрати фокусу. На малюнку 3 можна бачити пошук. Рисунок 3 – Пошук Щоб знайти конкретну задачу або переривання в режимі трасування, відкрийте Finder (поєднання клавіш «Ctrl-F). У діалоговому вікні «Finder» ви також можете вказати фільтри на властивості синхронізації, такі як час відгуку, щоб швидко знайти крайні випадки. На рисунку 4 показана історія об'єкта. Рисунок 4 – Перегляд історії об'єкта 21 Перегляд історії об'єкта дозволяє вам відстежувати конкретний об'єкт ядра, наприклад семафори і м'ютекси. Ви бачите всі операції з цим об'єктом і як його стан змінюється в результаті. Подвійне клацання в цьому поданні виділяє подія в основному поданні трасування. На рисунку 5 показана завантаженість процесора. Рисунок 5 – Графік завантаження процесора Графік завантаження ЦП відображає використання ЦП для кожної задачі і переривання в часі. Це можна збільшити окремо від основного подання трасування, а також можна використовувати для навігації за поданням трасування подвійним натисканням на графіку. 2.8 Уразливості Azure ThreadX Дослідники безпеки з компанії Embedi розкрили інформацію про уразливість в платформі ThreadX RTOS, активно застосовується для забезпечення роботи прошивок різних спеціалізованих одночіпових систем, в тому числі чіпів для організації бездротових комунікацій. Прошивки на базі ThreadX використовуються в більш ніж 6 мільярдів різних промислових і споживчих пристроїв. На прикладі бездротового чіпсету intel xscale Avastar 88w8897 продемонстрована можливість здійснення реальної віддаленої атаки, що дозволяє виконати код з привілеями ядра операційної системи через відправку спеціально оформленого WiFi-пакету. 22 Експлуатація уразливості в RTOS-оточенні ThreadX дозволяє отримати контроль над програмним оточенням, в якому виконується прошивка (сучасні WiFi чіпи реалізуються на базі архітектури FullMAC, що передбачає наявність спеціалізованого процесора, на якому виконується окрема операційна система з реалізацій свого бездротового стека). Дане оточення виконується в контексті бездротового чіпа і не має доступу до системної пам'яті (підключено через шину SDIO), тому для виконання атаки на основну систему застосовується ще одна уразливість в проприетарном модулі ядра для чіпів Marvell Avastar, що відповідає за взаємодію оточення прошивки і основної ОС. Експлуатація уразливість в драйвері здійснюється через відправку з боку Wi-Fi SoC некоректно оформлених команд через шину SDIO, що викликають переповнення стека. Виявлено кілька шляхів здійснення атаки, але найбільш простим є атака під час операції сканування мережі, яка автоматично запускається бездротовим чіпом раз в п'ять хвилин. Уразливість дозволяє досягти контрольованого переповнення буфера в оточенні на базі ThreadX при обробці спеціально оформленого пакету, отриманого під час сканування мережі. У разі вдалого збігу обставин атакуючий може переписати покажчик, який використовують для переходу при виконанні подальших операцій. Атака не вимагає виконання від користувача будь-яких дій - достатньо наявності активного Wi-Fi у жертви і знаходження в межах досяжності від бездротової точки доступу атакуючого. Імовірність успішного проведення атаки оцінюється в 50-60% для кожної спроби і залежить від стадії сканування, на якій виконана обробка пакета атакуючого. Чіп Marvell Avastar досить широко поширений і застосовується для забезпечення роботи Bluetooth і WiFi у багатьох смартфонах, планшетах, ноутбуках, медіацентри, домашніх маршрутизаторах, ігрових контролерах і автомобільних інформаційно-розважальних системах, у тому числі в таких пристроях, як Samsung Chromebook, Microsoft Surface, Sony PS4 і Valve Steamlink. Техніка експлуатації не специфічна для чіпів Marvell і 23 може бути адаптована для атаки на будь-які інші чіпи, в прошивках яких використовується RTOS ThreadX. Приклад успішної атаки продемонстрований для віддаленого отримання контролю за телеприставкой Valve Steamlink, основне програмне оточення якої побудовано на основі Dеbian і ядра Linux 3.8.13. 24 ВИСНОВКИ Системи реального часу зараз є затребуваним продуктом на ринку програмного забезпечення. Існує ціла гамма засобів даного напрямку, що покриває практично весь спектр можливих застосувань подібних систем підвищеної надійності. Microsoft Azure ThreadX являє собою гнучку ОСРЧ, яка підтримується і розвивається до сих пір. Завдяки швидкою роботою з пам'яттю та підтримки безлічі існуючих архітектур ThreadX займає передовиці позиції на ринку існуючих СРЧ. Але, нажаль, ThreadX має деякі недоліки, в особливості безпеки даних, що може стати ключовим елементом у виборі ОСРЧ для використання. 25 СПИСОК ЛІТЕРАТУРИ 1. Зыль С. Н. Проектирование, разработка и анализ программного обеспечения систем реального времени [Електронний ресурс] / Сергей Николаевич Зыль - Режим доступу до ресурсу: http://www.swd.rii/index.php37pichl043 2. Paul S. Dayan, The OS-9 Guru 1992 3. Dr. Jurgen Sauermann, Melanie Thelen «Real-time Operating Systems. Concepts and Implementation of Microkernels for Embedded Systems ». 4. Алан Джок «ОС реального часу». 5. Електронний ресурс https://docs.microsoft.com/en- us/azure/rtos/threadx/overview-threadx
