Відмінності між версіями «Linux сьогодні»

Матеріал з Вікі ЦДУ
Перейти до: навігація, пошук
(Linux 3.14)
(Linux 3.14)
Рядок 10: Рядок 10:
  
 
1. Пам'ять і системні сервіси
 
1. Пам'ять і системні сервіси
1.1. У планувальнику завдань забезпечена підтримка класу SCHED_DEADLINE , що реалізує алгоритм EDF ( Earliest Deadline First ), заснований на ідеї вибору завдання з черги чекають процесів , найбільш близькою до закінчення крайнього розрахункового часу ( deadline ) . SCHED_DEADLINE підтримує забезпечення роботи процесів, що вимагають виконання операцій в режимі реального часу , надаючи для подібних завдань гарантоване час виконання , незалежно від загальної кількості обслуговуваних процесів , і реалізуючи можливість резервування пропускної здатності CPU для процесів .
+
1.1. У планувальнику завдань забезпечена підтримка класу SCHED_DEADLINE , що реалізує алгоритм EDF ( Earliest Deadline First ), заснований на ідеї вибору завдання з черги чекають процесів , найбільш близькою до закінчення крайнього розрахункового часу ( deadline ) . SCHED_DEADLINE підтримує забезпечення роботи процесів, що вимагають виконання операцій в режимі реального часу , надаючи для подібних завдань гарантоване час виконання , незалежно від загальної кількості обслуговуваних процесів , і реалізуючи можливість резервування пропускної здатності CPU для процесів .
 
Раніше доступний планувальник завдань не міг забезпечити таку поведінку , оскільки не здатний гарантувати необхідний час виконання завдання в заданому інтервалі часу (наприклад , гарантувати виконання завдання 10 мкс в інтервалі 100 мкс ) через те , що перемикання між завданнями залежить від загальної кількості обслуговуваних процесів , кожен з яких може виконуватися з довільною затримкою і , таким чином , може затримати виконання наступного завдання .
 
Раніше доступний планувальник завдань не міг забезпечити таку поведінку , оскільки не здатний гарантувати необхідний час виконання завдання в заданому інтервалі часу (наприклад , гарантувати виконання завдання 10 мкс в інтервалі 100 мкс ) через те , що перемикання між завданнями залежить від загальної кількості обслуговуваних процесів , кожен з яких може виконуватися з довільною затримкою і , таким чином , може затримати виконання наступного завдання .
1.2. Зняття ярлика експериментальної розробки і перенесення з гілки staging в основне дерево ядра підсистеми zRAM , призначеної для зберігання розділу підкачки в пам'яті в стислому вигляді. Суть zRAM зводиться до того , що в пам'яті створюється блоковий пристрій на яке виробляється своппинг зі стисненням . В даний час zRAM вже активно використовується в різних споживчих пристроях , в тому числі в телеприставки і портативних пристроях на базі платформи Android , ChromeOS і Cyanogenmod .
+
1.2. Зняття ярлика експериментальної розробки і перенесення з гілки staging в основне дерево ядра підсистеми zRAM , призначеної для зберігання розділу підкачки в пам'яті в стислому вигляді. Суть zRAM зводиться до того , що в пам'яті створюється блоковий пристрій на яке виробляється своппинг зі стисненням . В даний час zRAM вже активно використовується в різних споживчих пристроях , в тому числі в телеприставки і портативних пристроях на базі платформи Android , ChromeOS і Cyanogenmod .
1.3. Підтримка тригерів в підсистемі обробки подій трасування , що дозволяє відстежити звернення до тих або інших функцій ядра. Тригери доповнюють раніше присутню можливість установки контрольних перевірок ( probe ) засобами прив'язки умовних команд , що викликаються при спрацьовуванні контрольної перевірки. Через дані команди можна виконувати дії, що дозволяють отримати додаткові відомості , такі як включення або виключення подій трасування або виконання трасування стека. Кожна команда може задаватися з використанням фільтра подій , що дозволяє триггеру спрацьовувати тільки при потрібних умовах. Наприклад, виконання " echo ' stacktrace : 5 if bytes_req > = 65536 '> / sys / kernel / debug / tracing / events / kmem / kmalloc / trigger " призведе до установки тригера , що видає трасування стека для перших п'яти запитів до kmalloc з розміром більше 64 Кб.
+
1.3. Підтримка тригерів в підсистемі обробки подій трасування , що дозволяє відстежити звернення до тих або інших функцій ядра. Тригери доповнюють раніше присутню можливість установки контрольних перевірок ( probe ) засобами прив'язки умовних команд , що викликаються при спрацьовуванні контрольної перевірки. Через дані команди можна виконувати дії, що дозволяють отримати додаткові відомості , такі як включення або виключення подій трасування або виконання трасування стека. Кожна команда може задаватися з використанням фільтра подій , що дозволяє триггеру спрацьовувати тільки при потрібних умовах. Наприклад, виконання " echo ' stacktrace : 5 if bytes_req > = 65536 '> / sys / kernel / debug / tracing / events / kmem / kmalloc / trigger " призведе до установки тригера , що видає трасування стека для перших п'яти запитів до kmalloc з розміром більше 64 Кб.
1.4. В системі контрольних перевірок uprobes ( userspace probes ) , використовуваної для аналізу поведінки виконуваних в просторі користувача додатків , додана підтримка вилучення даних з стека і пам'яті користувача процесу , а також обробка таких типів аргументів , як разименованія , бітові поля , повертаються функцією значення і зміщення в файлах. Uprobes можна використовувати для визначення вузьких місць в продуктивності , накопичувати налагоджувальні дані та інформацію про час виконання різних частин додатка в повністю прозорому режимі , ніяким чином не впливаючи на роботу відслідковується процесу . Запустити і зупинити збір даних можна в будь-який момент , без перезапуску або модифікації програми .
+
1.4. В системі контрольних перевірок uprobes ( userspace probes ) , використовуваної для аналізу поведінки виконуваних в просторі користувача додатків , додана підтримка вилучення даних з стека і пам'яті користувача процесу , а також обробка таких типів аргументів , як разименованія , бітові поля , повертаються функцією значення і зміщення в файлах. Uprobes можна використовувати для визначення вузьких місць в продуктивності , накопичувати налагоджувальні дані та інформацію про час виконання різних частин додатка в повністю прозорому режимі , ніяким чином не впливаючи на роботу відслідковується процесу . Запустити і зупинити збір даних можна в будь-який момент , без перезапуску або модифікації програми .
  
 
== Виявлення великої кількості вірусів для Linux ==
 
== Виявлення великої кількості вірусів для Linux ==

Версія за 23:07, 27 травня 2014

Linux 3.14



Після двох місяців розробки Лінус Торвальдс випустив ядро Linux 3.14 . Серед найбільш помітних поліпшень : новий клас планування завдань Deadline , блоковий пристрій zRAM для зберігання розділу підкачки в ОЗУ в стислому вигляді, підтримка режиму PVH в Xen, підтримка тригерів в системі трасування , засоби для налагодження блокувань в просторі користувача, планувальник пакетів PIE, механізм захисту KASLR ( рандомізація пам'яті ядра), виділення з sysfs підсистеми kernfs , з Android перенесена система розподілу пам'яті ION.

У нову версію прийнято більше 12 тисяч виправлень від майже 1400 розробників , розмір патча - 39 Мб ( зміни торкнулися 10.6 тисяч файлів , додано 606 195 рядків коду , видалено 265086 рядків). Близько 46 % всіх представлених в 3.14 змін пов'язані з драйверами пристроїв , приблизно 19 % змін мають відношення до оновлення коду специфічного для апаратних архітектур , 16 % пов'язано з мережевим стеком , 5 % - файловими системами і 3% c внутрішніми підсистемами ядра. 10.2% змін внесено співробітниками компанії Intel , 7.3 % - Red Hat , 4.4% - Linaro , 5 % - Samsung , 3.3% - SUSE , 2.9% - IBM , 2.7% - Google , 2.4% - TI , 2.1% - NVIDIA , 2.0 % - FOSS Outreach Program for Women , 1.8% - Huawei , 1.3% - Oracle. З найбільш цікавих нововведень можна відзначити:

1. Пам'ять і системні сервіси 1.1. У планувальнику завдань забезпечена підтримка класу SCHED_DEADLINE , що реалізує алгоритм EDF ( Earliest Deadline First ), заснований на ідеї вибору завдання з черги чекають процесів , найбільш близькою до закінчення крайнього розрахункового часу ( deadline ) . SCHED_DEADLINE підтримує забезпечення роботи процесів, що вимагають виконання операцій в режимі реального часу , надаючи для подібних завдань гарантоване час виконання , незалежно від загальної кількості обслуговуваних процесів , і реалізуючи можливість резервування пропускної здатності CPU для процесів . Раніше доступний планувальник завдань не міг забезпечити таку поведінку , оскільки не здатний гарантувати необхідний час виконання завдання в заданому інтервалі часу (наприклад , гарантувати виконання завдання 10 мкс в інтервалі 100 мкс ) через те , що перемикання між завданнями залежить від загальної кількості обслуговуваних процесів , кожен з яких може виконуватися з довільною затримкою і , таким чином , може затримати виконання наступного завдання . 1.2. Зняття ярлика експериментальної розробки і перенесення з гілки staging в основне дерево ядра підсистеми zRAM , призначеної для зберігання розділу підкачки в пам'яті в стислому вигляді. Суть zRAM зводиться до того , що в пам'яті створюється блоковий пристрій на яке виробляється своппинг зі стисненням . В даний час zRAM вже активно використовується в різних споживчих пристроях , в тому числі в телеприставки і портативних пристроях на базі платформи Android , ChromeOS і Cyanogenmod . 1.3. Підтримка тригерів в підсистемі обробки подій трасування , що дозволяє відстежити звернення до тих або інших функцій ядра. Тригери доповнюють раніше присутню можливість установки контрольних перевірок ( probe ) засобами прив'язки умовних команд , що викликаються при спрацьовуванні контрольної перевірки. Через дані команди можна виконувати дії, що дозволяють отримати додаткові відомості , такі як включення або виключення подій трасування або виконання трасування стека. Кожна команда може задаватися з використанням фільтра подій , що дозволяє триггеру спрацьовувати тільки при потрібних умовах. Наприклад, виконання " echo ' stacktrace : 5 if bytes_req > = 65536 '> / sys / kernel / debug / tracing / events / kmem / kmalloc / trigger " призведе до установки тригера , що видає трасування стека для перших п'яти запитів до kmalloc з розміром більше 64 Кб. 1.4. В системі контрольних перевірок uprobes ( userspace probes ) , використовуваної для аналізу поведінки виконуваних в просторі користувача додатків , додана підтримка вилучення даних з стека і пам'яті користувача процесу , а також обробка таких типів аргументів , як разименованія , бітові поля , повертаються функцією значення і зміщення в файлах. Uprobes можна використовувати для визначення вузьких місць в продуктивності , накопичувати налагоджувальні дані та інформацію про час виконання різних частин додатка в повністю прозорому режимі , ніяким чином не впливаючи на роботу відслідковується процесу . Запустити і зупинити збір даних можна в будь-який момент , без перезапуску або модифікації програми .

Виявлення великої кількості вірусів для Linux



Проте виникли деякі проблеми, а саме у травні 2014 число виявлених троянів для Linux досягло рекорду в порівнянні з попередніми місяцями. Значна частина з них була призначена для проведення DDoS- атак , повідомляє розробник антивірусів « Доктор Веб» . « Стереотипну думку про те , що операційні системи, побудовані на базі ядра Linux , в силу особливостей своєї архітектури повністю захищені від проникнення шкідливих програм , помітно полегшує життя зловмисникам , що поширює подібне ПО » , - прокоментували аналітики. У компанії не повідомили точну кількість виявлених загроз , але в повідомленні прес -служби « Доктора Веба » фігурують дев'ять різновидів шкідливого коду. Список шкідливих програм розділений на три частини: група Linux.DDoS , група Linux.DnsAmp і Linux.Mrblack . У першу групу увійшли трояни Linux.DDoS.3 , Linux.DDoS.22 і Linux.DDoS.24 , що володіють широким спектром функціональних можливостей. Після запуску вони визначають адресу командного сервера і відправляють на нього інформацію про зараженій системі , а потім очікують отримання конфігураційних даних з параметрами поточного завдання (звіт про її виконання також згодом вирушає зловмисникам ) . Трояни групи Linux.DDoS дозволяють здійснювати DDoS- атаки на заданий сервер з використанням протоколів TCP / IP ( TCP Flood ) , UDP ( UDP Flood ) , а також відправляють запити на сервери DNS для посилення ефективності атак ( DNS Amplification ). Модифікація Linux.DDoS.22 орієнтована на роботу з дистрибутивами Linux для процесорів ARM , а Linux.DDoS.24 здатний заражати сервери і робочі станції , на яких використовуються 32 - розрядні версії Ubuntu і CentOS . Друга група - Linux.DnsAmp.1 , Linux.DnsAmp.2 , Linux.DnsAmp.3 , Linux.DnsAmp.4 і Linux.DnsAmp.5 . Подібно іншим представникам цього класу DDoS- троянців , Linux.DnsAmp реєструє себе в автозавантаженні , збирає і відправляє на віддалений сервер відомості про конфігурацію зараженої машини (версія ОС , частота процесора , обсяг вільної пам'яті і т. д.) , після чого очікує надходження керуючих команд. Трояни групи Linux.DnsAmp дозволяють проводити атаки виду SYN Flood ( відправка великої кількості запитів на ініціалізацію TCP -з'єднань ) , UDP Flood ( відправка безлічі пакетів UDP ) і Ping Flood ( відправка пакетів ICMP ) . Трояни цієї групи використовують технології посилення DDoS- атак DNS Amplification і NTP Amplification . Нарешті , шкідливий Linux.Mrblack призначений для ARM- сумісних дистрибутивів Linux. Троянець також призначений для проведення DDoS- атак з використанням протоколів TCP / IP і HTTP. Він має досить примітивну архітектуру і , подібно іншим аналогічним загрозам , діє за командою з керуючого сервера. « Командні центри , з використанням яких здійснюється управління згаданими троянськими програмами , розташовуються переважно на території Китаю , і реалізовані з їх допомогою DDoS- атаки спрямовані, в основному , проти китайських інтернет- ресурсів» , - розповіли в компанії « Доктор Веб» Зазначені шкідливі програми об'єднують спільні риси, включаючи призначення і використовувані протоколи і пакети. Фахівці «Доктор Веб» припускають, що більшість з них були створені одним і тим же автором.

Випуск антивірусу Dr.Web для Linux 9.0


Компанія "Dr.Web" повідомляє про випуск Антивірусу Dr.Web для Linux версії 9.0. Було внесено ряд поліпшень, які підвищили швидкість і ефективність сканування, також були реалізовані зміни для більш зручної роботи з продуктом. Змінено порядок видачі демо-ліцензій: вони доступні тепер в 2 варіантах - на 90 і на 30 днів (в останньому випадку при отриманні демонстраційного ключового файлу введення персональних даних не потрібно). Демо-ліцензію можна отримати один раз на рік. Графічний інтерфейс Антивіруса Dr.Web для Linux був повністю перероблений. Для зручності користувачів були також оптимізовані налаштування роботи антивіруса. Сканування проходить тепер в декілька потоків , що дозволяє помітно підвищити швидкість перевірки на багатоядерних процесорах. Всі компоненти були перероблені з метою скорочення навантаження на процесор і зменшення споживання пам'яті. Значні зміни у файловому моніторі SpIDer Guard дозволили збільшити надійність і швидкість його роботи. Додана утиліта командного рядка , що володіє широкою функціональністю . Продукт тепер має можливість сканування запущених процесів для знешкодження активних загроз.