Віртуалізація файлових дескрипторів WebAssembly WASI: відкриваючи універсальну абстракцію ресурсів

У світі розподілених обчислень, що стрімко розвивається, пошук одночасно безпечних, високопортативних та неймовірно ефективних застосунків став першочерговим завданням. Розробники та архітектори по всьому світу стикаються з викликами, пов'язаними з гетерогенними операційними системами, різноманітними апаратними архітектурами та постійною потребою у надійних межах безпеки. Цей глобальний виклик призвів до появи WebAssembly (Wasm) та його системного інтерфейсу WASI (WebAssembly System Interface) як потужної зміни парадигми.

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

Вічний виклик: поєднання коду та конкретних ресурсів

Перш ніж ми розберемо рішення WASI, важливо зрозуміти фундаментальну проблему, яку воно вирішує. Програмні застосунки, незалежно від їх складності, неминуче повинні взаємодіяти із зовнішніми ресурсами. Це включає читання та запис файлів, надсилання та отримання даних через мережу, доступ до поточного часу, генерацію випадкових чисел або запит змінних середовища. Традиційно ці взаємодії виконуються через системні виклики — специфічні функції, що надаються ядром операційної системи (ОС).

«Нативна» дилема: специфічні для ОС інтерфейси та властиві ризики

Розглянемо програму, написану на C або Rust, призначену для збереження даних у файл. У системі Linux вона може використовувати стандартні функції POSIX, такі як open(), write() та close(). У системі Windows вона буде використовувати Win32 API, такі як CreateFile(), WriteFile() та CloseHandle(). Ця разюча відмінність означає, що код, написаний для однієї ОС, часто вимагає значних модифікацій або зовсім інших реалізацій для запуску на іншій. Ця відсутність портативності створює значні накладні витрати на розробку та підтримку для застосунків, орієнтованих на глобальну аудиторію або різноманітні середовища розгортання.

Крім портативності, прямий доступ до системних викликів становить значні вразливості безпеки. Шкідливий або скомпрометований застосунок, отримавши необмежений доступ до повного спектра системних викликів ОС, потенційно може:

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

Традиційні стратегії стримування, такі як віртуальні машини (ВМ) або контейнери (наприклад, Docker), пропонують шар ізоляції. Однак ВМ мають значні накладні витрати, а контейнери, хоч і легші, все ж покладаються на спільні ресурси ядра і вимагають ретельної конфігурації для запобігання «втечам з контейнера» або надмірному доступу. Вони забезпечують ізоляцію на рівні процесу, але не обов'язково на детальному рівні ресурсів, на який націлені Wasm та WASI.

Імператив «пісочниці»: безпека без шкоди для функціональності

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

WebAssembly (Wasm): універсальний бінарний формат

Перш ніж глибше зануритися в інновації WASI, коротко розглянемо сам WebAssembly. Wasm — це низькорівневий формат байт-коду, призначений для високопродуктивних застосунків. Він пропонує кілька вагомих переваг:

• Портативність: Байт-код Wasm є незалежним від платформи, що означає, що він може працювати на будь-якій системі, де є середовище виконання Wasm, незалежно від базової архітектури процесора чи операційної системи. Це схоже на принцип Java «написав один раз, запускай скрізь», але на значно нижчому рівні, ближче до нативної продуктивності.
• Продуктивність: Wasm розроблений для швидкості виконання, близької до нативної. Він компілюється у високооптимізований машинний код середовищем виконання Wasm, що робить його ідеальним для завдань, інтенсивних до процесора.
• Безпека: Wasm за замовчуванням виконується в безпечній пісочниці з безпечною пам'яттю. Він не може безпосередньо отримати доступ до пам'яті або ресурсів хост-системи, якщо на це не буде явно надано дозвіл середовищем виконання Wasm.
• Незалежність від мови: Розробники можуть компілювати код, написаний різними мовами (Rust, C/C++, Go, AssemblyScript та багато інших), у Wasm, що дозволяє поліглотну розробку без залежностей від середовища виконання конкретної мови.
• Малий розмір: Модулі Wasm зазвичай дуже малі, що призводить до швидшого завантаження, меншого споживання пам'яті та швидшого часу запуску, що є критично важливим для периферійних та безсерверних середовищ.

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

WASI: точне поєднання WebAssembly та хост-системи

WASI, або WebAssembly System Interface, — це модульна колекція стандартизованих API, які дозволяють модулям WebAssembly безпечно взаємодіяти з хост-середовищами. Він розроблений як незалежний від ОС, що дозволяє модулям Wasm досягти справжньої портативності за межами браузера.

Роль системних інтерфейсів: контракт на взаємодію

Думайте про WASI як про стандартизований контракт. Модуль Wasm, написаний відповідно до специфікації WASI, точно знає, які функції він може викликати для запиту системних ресурсів (наприклад, «відкрити файл», «читати з сокета»). Середовище виконання Wasm, яке розміщує та виконує модуль Wasm, відповідає за реалізацію цих функцій WASI, перетворюючи абстрактні запити на конкретні операції на хост-ОС. Цей шар абстракції є ключем до потужності WASI.

Принципи дизайну WASI: безпека на основі можливостей та детермінізм

Дизайн WASI значною мірою базується на безпеці на основі можливостей (capability-based security). Замість того, щоб модуль Wasm мав загальний дозвіл на виконання певних дій (наприклад, «доступ до всіх файлів»), він отримує лише конкретні «можливості» для конкретних ресурсів. Це означає, що хост явно надає модулю Wasm лише ті дозволи, які йому потрібні для обмеженого набору ресурсів. Цей принцип значно зменшує поверхню атаки.

Іншим важливим принципом є детермінізм. Для багатьох випадків використання, особливо в таких сферах, як блокчейн або відтворювані збірки, життєво важливо, щоб модуль Wasm, отримавши однакові вхідні дані, завжди видавав однаковий результат. WASI розроблений для сприяння цьому, надаючи чітко визначену поведінку для системних викликів, зменшуючи недетермінізм, де це можливо.

Віртуалізація файлових дескрипторів: глибоке занурення в абстракцію ресурсів

Тепер перейдемо до суті справи: як WASI досягає абстракції ресурсів через віртуалізацію файлових дескрипторів. Цей механізм є центральним для обіцянки WASI щодо безпеки та портативності.

Що таке файловий дескриптор? (Традиційний погляд)

У традиційних Unix-подібних операційних системах файловий дескриптор (ФД) є абстрактним індикатором (зазвичай невід'ємним цілим числом), що використовується для доступу до файлу або іншого ресурсу вводу/виводу, такого як канал, сокет або пристрій. Коли програма відкриває файл, ОС повертає файловий дескриптор. Програма потім використовує цей ФД для всіх подальших операцій з цим файлом, таких як читання, запис або пошук. ФД є фундаментальними для взаємодії процесів із зовнішнім світом.

Проблема з традиційними ФД з точки зору Wasm полягає в тому, що вони специфічні для хоста. Номер ФД в одній ОС може відповідати зовсім іншому ресурсу, або навіть бути недійсним, в іншій. Більше того, пряма маніпуляція хостовими ФД обходить будь-яку пісочницю, надаючи модулю Wasm необмежений доступ.

Віртуальні файлові дескриптори WASI: шар абстракції

WASI вводить власну концепцію віртуальних файлових дескрипторів. Коли модуль Wasm, скомпільований з WASI, потребує взаємодії з файлом або мережевим сокетом, він не взаємодіє безпосередньо з файловими дескрипторами хост-ОС. Замість цього він робить запит до середовища виконання WASI, використовуючи визначений WASI API (наприклад, wasi_snapshot_preview1::fd_read).

Ось як це працює:

1. Попереднє відкриття хостом: Ще до того, як модуль Wasm почне виконуватися, хост-середовище (середовище виконання Wasm) явно «попередньо відкриває» конкретні каталоги або ресурси для модуля. Наприклад, хост може вирішити, що модуль Wasm може отримувати доступ лише до файлів у певному каталозі, скажімо /my-data, і надати йому доступ лише для читання.
2. Призначення віртуального ФД: Для кожного попередньо відкритого ресурсу хост призначає віртуальний файловий дескриптор (ціле число), який має значення *лише в межах пісочниці модуля Wasm*. Ці віртуальні ФД зазвичай мають номер 3 або вище, оскільки ФД 0, 1 і 2 традиційно зарезервовані для стандартного вводу, стандартного виводу та стандартної помилки відповідно, які також віртуалізуються WASI.
3. Надання можливостей: Разом із віртуальним ФД хост також надає певний набір можливостей (дозволів) для цього віртуального ФД. Ці можливості є гранулярними і точно визначають, які дії модуль Wasm може виконувати з цим ресурсом. Наприклад, каталог може бути попередньо відкритий з віртуальним ФД (наприклад, 3) і можливостями для read, write та create_file. Інший файл може бути попередньо відкритий з віртуальним ФД 4 і лише з можливістю read.
4. Взаємодія модуля Wasm: Коли модуль Wasm хоче прочитати з файлу, він викликає функцію WASI, таку як wasi_snapshot_preview1::path_open, вказуючи шлях відносно одного зі своїх попередньо відкритих каталогів (наприклад, "data.txt" відносно віртуального ФД 3). У разі успіху середовище виконання WASI повертає *інший* віртуальний ФД для нововідкритого файлу разом з його конкретними можливостями. Потім модуль використовує цей новий віртуальний ФД для операцій читання/запису.
5. Відображення на хості: Середовище виконання Wasm на хості перехоплює ці виклики WASI. Воно перевіряє віртуальний ФД, верифікує запитану дію на відповідність наданим можливостям, а потім перетворює цей віртуальний запит у відповідний *нативний* системний виклик на хост-ОС, використовуючи фактичний, базовий файловий дескриптор хоста, на який відображається попередньо відкритий ресурс.

Весь цей процес відбувається прозоро для модуля Wasm. Модуль Wasm бачить і оперує лише своїми абстрактними, віртуальними файловими дескрипторами та пов'язаними з ними можливостями. Він не має жодної інформації про базову структуру файлової системи хоста, його нативні ФД або його специфічні конвенції системних викликів.

Ілюстративний приклад: попереднє відкриття каталогу

Уявіть модуль Wasm, призначений для обробки зображень. Хост-середовище може запустити його за допомогою команди на зразок:

wasmtime --mapdir /in::/var/data/images --mapdir /out::/tmp/processed-images image-processor.wasm

У цьому сценарії:

• Хостове середовище виконання Wasm (наприклад, Wasmtime) попередньо відкриває два каталоги хоста: /var/data/images та /tmp/processed-images.
• Воно відображає /var/data/images на віртуальний шлях модуля Wasm /in і надає йому, скажімо, можливості read та lookup. Це означає, що модуль Wasm може переглядати список файлів і читати файли у своєму віртуальному каталозі /in.
• Воно відображає /tmp/processed-images на віртуальний шлях модуля Wasm /out і надає йому, скажімо, можливості write, create_file та remove_file. Це дозволяє модулю Wasm записувати оброблені зображення у свій віртуальний каталог /out.
• Модуль Wasm, коли йому потрібно відкрити /in/picture.jpg, отримує віртуальний ФД для цього файлу. Потім він може читати дані зображення, використовуючи цей віртуальний ФД. Коли він закінчує обробку і хоче зберегти результат, він відкриває /out/picture-processed.png, отримує інший віртуальний ФД і використовує його для запису нового файлу.

Модуль Wasm абсолютно не знає, що /in на хості насправді є /var/data/images, або що /out є /tmp/processed-images. Він знає лише про свою пісочницю, віртуальну файлову систему.

Практичні наслідки та переваги для глобальної екосистеми

Краса віртуалізації файлових дескрипторів WASI виходить далеко за рамки простої технічної елегантності; вона відкриває глибокі переваги для розробників та організацій, що працюють у глобально різноманітному технологічному ландшафті:

1. Неперевершена безпека: принцип найменших привілеїв у дії

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

• Виходити за межі призначених каталогів: Модуль, призначений для доступу до /data, не може раптово спробувати прочитати /etc/passwd.
• Виконувати неавторизовані операції: Модуль, якому надано доступ лише для читання, не може записувати або видаляти файли.
• Отримувати доступ до ресурсів, які не були явно надані: Якщо ресурс не було попередньо відкрито, він недоступний. Це усуває багато поширених векторів атак і робить модулі Wasm значно безпечнішими для запуску, навіть із недовірених джерел. Цей рівень безпеки є критично важливим для багатокористувацьких середовищ, таких як безсерверні обчислення, де код від різних користувачів виконується на одній інфраструктурі.

2. Покращена портативність: написав один раз, запускай дійсно скрізь

Оскільки модуль Wasm працює виключно з абстрактними, віртуальними файловими дескрипторами та API WASI, він стає повністю відокремленим від базової операційної системи хоста. Той самий бінарний файл Wasm може безперешкодно працювати на:

• Серверах Linux (використовуючи середовища виконання `wasmedge`, `wasmtime` або `lucet`).
• Машинах з Windows (використовуючи сумісні середовища виконання).
• Робочих станціях macOS.
• Периферійних пристроях (таких як Raspberry Pi або навіть мікроконтролери зі спеціалізованими середовищами виконання).
• Хмарних середовищах (на різних віртуальних машинах або контейнерних платформах).
• Вбудованих системах, що реалізують специфікацію WASI.

Хостове середовище виконання обробляє перетворення віртуальних ФД та шляхів WASI у нативні виклики ОС. Це значно зменшує зусилля на розробку, спрощує конвеєри розгортання та дозволяє розгортати застосунки в найбільш оптимальному середовищі без перекомпіляції або перепроєктування.

3. Надійна ізоляція: запобігання бічному руху та втручанню

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

4. Спрощене розгортання та конфігурація

Для операційних команд у всьому світі WASI спрощує розгортання. Замість необхідності налаштовувати складні оркестрації контейнерів з монтуванням томів та контекстами безпеки, специфічними для кожного застосунку, вони можуть просто визначити явні відображення ресурсів та можливостей під час виклику середовища виконання Wasm. Це призводить до більш передбачуваних та аудитованих розгортань.

5. Покращена компонованість: побудова з безпечних, незалежних блоків

Чіткі інтерфейси та сильна ізоляція, що надаються WASI, дозволяють розробникам створювати складні застосунки, компонуючи менші, незалежні модулі Wasm. Кожен модуль може бути розроблений та захищений окремо, а потім інтегрований, знаючи, що його доступ до ресурсів суворо контролюється. Це сприяє модульній архітектурі, повторному використанню та зручності обслуговування.

Абстракція ресурсів на практиці: не лише файли

Хоча термін «віртуалізація файлових дескрипторів» може наводити на думку про фокус виключно на файлах, абстракція ресурсів WASI поширюється на багато інших фундаментальних системних ресурсів:

1. Мережеві сокети

Подібно до файлів, WASI також віртуалізує операції з мережевими сокетами. Модуль Wasm не може довільно відкрити будь-яке мережеве з'єднання. Натомість хостове середовище виконання має явно надати йому дозвіл на:

• Прив'язку до конкретних локальних адрес та портів: наприклад, лише до порту 8080.
• Підключення до конкретних віддалених адрес та портів: наприклад, лише до api.example.com:443.

Модуль Wasm запитує сокет (отримуючи віртуальний ФД), а хостове середовище виконання керує фактичним з'єднанням TCP/UDP. Це запобігає скануванню внутрішніх мереж або запуску зовнішніх атак шкідливим модулем.

2. Годинники та таймери

Доступ до поточного часу або встановлення таймерів — це ще одна взаємодія, яку абстрагує WASI. Хост надає віртуальний годинник модулю Wasm, який може запитувати час або встановлювати таймер без прямої взаємодії з апаратним годинником хоста. Це важливо для детермінізму та запобігання маніпуляціям системним часом з боку модулів.

3. Змінні середовища

Змінні середовища часто містять конфіденційні дані конфігурації (наприклад, облікові дані бази даних, ключі API). WASI дозволяє хосту явно надавати *лише* необхідні змінні середовища модулю Wasm, замість того, щоб розкривати всі змінні середовища хоста. Це запобігає витоку інформації.

4. Генерація випадкових чисел

Криптографічно безпечна генерація випадкових чисел є критично важливою для багатьох застосунків. WASI надає API для модулів Wasm для запиту випадкових байтів. Хостове середовище виконання відповідає за надання високоякісних, безпечно згенерованих випадкових чисел, абстрагуючи специфіку генератора випадкових чисел хоста (наприклад, /dev/urandom на Linux або `BCryptGenRandom` на Windows).

Глобальний вплив та трансформаційні сценарії використання

Поєднання продуктивності та портативності WebAssembly з безпечною абстракцією ресурсів WASI готове стимулювати інновації в різних глобальних галузях:

1. Периферійні обчислення та IoT: безпечний код на пристроях з обмеженими ресурсами

Периферійні пристрої часто мають обмежені ресурси (ЦП, пам'ять, сховище) і працюють у потенційно небезпечних або недовірених середовищах. Малий розмір Wasm та сильна модель безпеки WASI роблять його ідеальним для розгортання логіки застосунків на периферійних пристроях. Уявіть собі камеру безпеки, що виконує модуль Wasm для висновків ШІ, якому дозволено лише читати з потоку камери та записувати оброблені дані на конкретну мережеву кінцеву точку, без будь-якого іншого доступу до системи. Це гарантує, що навіть якщо модуль ШІ буде скомпрометований, сам пристрій залишиться в безпеці.

2. Безсерверні функції: багатокористувацькість нового покоління

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

3. Мікросервіси та поліглотні архітектури: компоненти, незалежні від мови

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

4. Блокчейн та смарт-контракти: детерміноване та надійне виконання

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

5. Безпечні системи плагінів та розширень: безпечне розширення можливостей застосунків

Багато застосунків, від веб-браузерів до систем управління контентом, пропонують архітектури плагінів. Інтеграція коду сторонніх розробників завжди несе ризики безпеки. Запускаючи плагіни як модулі Wasm з підтримкою WASI, розробники застосунків можуть точно контролювати, до яких ресурсів кожен плагін може отримати доступ. Плагін для редагування фотографій, наприклад, може отримати дозвіл лише на читання файлу зображення, який йому надано, і запис зміненої версії, без доступу до мережі або ширших дозволів файлової системи.

Виклики та майбутні напрямки для універсальної абстракції

Хоча віртуалізація файлових дескрипторів та абстракція ресурсів WASI пропонують величезні переваги, екосистема все ще розвивається:

1. Еволюція стандартів: асинхронний ввід/вивід та модель компонентів

Початкова специфікація WASI, wasi_snapshot_preview1, переважно підтримує синхронний ввід/вивід, що може бути вузьким місцем продуктивності для застосунків з інтенсивним мережевим навантаженням. Ведуться роботи зі стандартизації асинхронного вводу/виводу та більш надійної моделі компонентів (Component Model) для Wasm. Модель компонентів має на меті зробити модулі Wasm справді компонованими та взаємосумісними, дозволяючи їм безпечно та ефективно спілкуватися, не знаючи внутрішніх деталей один одного. Це ще більше посилить можливості спільного використання ресурсів та абстракції.

2. Питання продуктивності глибокої віртуалізації

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

3. Інструментарій та зрілість екосистеми

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

Висновок: розширення можливостей нового покоління хмарно-нативних та периферійних застосунків

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

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

Прийміть майбутнє безпечних, портативних обчислень із революційним підходом WebAssembly та WASI до абстракції ресурсів. Шлях до справді універсального розгортання застосунків вже розпочато, і віртуалізація файлових дескрипторів є наріжним каменем цього трансформаційного руху.