Відмінності між версіями «Linux сьогодні»
(→Linux 3.14) |
|||
(не показані 2 проміжні версії цього учасника) | |||
Рядок 1: | Рядок 1: | ||
+ | |||
+ | |||
+ | |||
== Linux 3.14 == | == Linux 3.14 == | ||
---- | ---- | ||
− | + | [[Файл:linux_logo.jpg]] | |
Після двох місяців розробки Лінус Торвальдс випустив ядро Linux 3.14 . Серед найбільш помітних поліпшень : новий клас планування завдань Deadline , блоковий пристрій zRAM для зберігання розділу підкачки в ОЗУ в стислому вигляді, підтримка режиму PVH в Xen, підтримка тригерів в системі трасування , засоби для налагодження блокувань в просторі користувача, планувальник пакетів PIE, механізм захисту KASLR ( рандомізація пам'яті ядра), виділення з sysfs підсистеми kernfs , з Android перенесена система розподілу пам'яті ION. | Після двох місяців розробки Лінус Торвальдс випустив ядро Linux 3.14 . Серед найбільш помітних поліпшень : новий клас планування завдань Deadline , блоковий пристрій zRAM для зберігання розділу підкачки в ОЗУ в стислому вигляді, підтримка режиму PVH в Xen, підтримка тригерів в системі трасування , засоби для налагодження блокувань в просторі користувача, планувальник пакетів PIE, механізм захисту KASLR ( рандомізація пам'яті ядра), виділення з sysfs підсистеми kernfs , з Android перенесена система розподілу пам'яті ION. | ||
Рядок 73: | Рядок 76: | ||
'''5. Обладнання''' | '''5. Обладнання''' | ||
− | 5.1. Підтримка перемикання відеорежимів в просторі користувача ( UMS ) в DRM- драйвері Intel i915 оголошена застарілою і буде видалена з працюючих на рівні ядра компонентів драйвера через рік. Доведена до стабільного стану підтримка графічної підсистеми процесорів на базі мікроархітектури Broadwell , яка прийде на зміну Haswell . | + | 5.1. Підтримка перемикання відеорежимів в просторі користувача ( UMS ) в DRM- драйвері Intel i915 оголошена застарілою і буде видалена з працюючих на рівні ядра компонентів драйвера через рік. Доведена до стабільного стану підтримка графічної підсистеми процесорів на базі мікроархітектури Broadwell , яка прийде на зміну Haswell. |
5.2. У DRM- модулі драйвера Nouveau додана підтримка GPU NVIDIA серії GK110 ( GeForce GTX 780 , GTX Titan ) і GK208 (GeForce 630 /640) . | 5.2. У DRM- модулі драйвера Nouveau додана підтримка GPU NVIDIA серії GK110 ( GeForce GTX 780 , GTX Titan ) і GK208 (GeForce 630 /640) . | ||
Рядок 90: | Рядок 93: | ||
5.9. Підтримка криптографічних сопроцессоров AMD ( CCP ) і Freescale MXS DCP . | 5.9. Підтримка криптографічних сопроцессоров AMD ( CCP ) і Freescale MXS DCP . | ||
+ | |||
+ | == Linux 3.15 буде прокидатися в 7-12 разів швидше == | ||
+ | |||
+ | ---- | ||
+ | |||
+ | Розробники з компанії Intel запропонували включити в ядро Linux 3.15 патч , який значно прискорює процес виходу системи з сну. На тестових системах патч показує прискорення в 7-12 разів. | ||
+ | |||
+ | Розробники оптимізували деякі процедури на рівні драйверів ATA і SCSI. Як видно на графіках , ефект досягнуто за рахунок оптимізації асинхронного виконання процесів . При цьому підвищується швидкість та догляду в сплячий режим , і виходу з нього. Драйвери тепер більш інтелектуально обробляють виклики з ядра Linux , ставлячи їх у чергу . Таким чином , система здається відновленній після сну , хоча деякі процеси все ще довантажуються з жорсткого диска. | ||
+ | |||
+ | На тестовому комп'ютері Intel Core i7-3960X (3,3 ГГц) з SATA-контролером Intel C600/X79 і шістьма підключеними накопичувачами (SSD, DVD-ROM і 4 HDD) швидкість відходу в сплячий режим скоротилася з 2479 до 2417 мс, а відновлення - з 11656 до 1110 мс, тобто в 10,5 разів. | ||
+ | |||
+ | На іншому комп'ютері з єдиним HDD перший показник зменшився з 1897 до 1728 мс, а другий - з 5416 до 448 мс, тобто в 12 разів. | ||
== Виявлення великої кількості вірусів для Linux == | == Виявлення великої кількості вірусів для Linux == |
Поточна версія на 23:40, 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 можна використовувати для визначення вузьких місць в продуктивності , накопичувати налагоджувальні дані та інформацію про час виконання різних частин додатка в повністю прозорому режимі , ніяким чином не впливаючи на роботу відслідковується процесу . Запустити і зупинити збір даних можна в будь-який момент , без перезапуску або модифікації програми .
1.5. Забезпечена можливість використання реалізованої на рівні ядра системи lockdep для налагодження функціонування блокувань в просторі користувача (зокрема , для виявлення взаємних блокувань в багатопоточних програмах ) .
1.6. До складу ядра прийнятий набір патчів biovec , що вносить деякі зміни в API блочного рівня ядра , в тому числі добавляющие підтримку створення довільних великих запитів введення / виводу і збільшують ефективність роботи.
1.7. Додана можливість використання системного виклику kexec ( ) на системах з EFI BIOS . Kexec надає можливість завантаження нового екземпляра ядра з вже запущеного ядра Linux , забезпечуючи варіант м'якого перезавантаження , без повернення управління в BIOS.
1.8. Значно перероблено внутрішній устрій віртуальної файлової системи sysfs . У підсумку , представлена нова підсистема " kernfs ", на якій тепер базується sysfs і яка може виступати в якості основи для інших віртуальних ФС . Наприклад , планується створити віртуальну ФС для управління cgroup .
1.9. Реалізована інфраструктура компонентних підсистем ( " componentized subsystems " ), призначена для управління складними пристроями , що складаються з декількох взаємодіючих один з одним більш простих пристроїв. У підсистему perf events додана підтримка механізму обліку енергоспоживання " RAPL " , використовуваного в процесорах Intel. Додана серія нових опцій в утиліту perf .
1.10. В експериментальну staging - гілку доданий використовуваний в платформі Android механізм розподілу пам'яті ION , націлений на ефективне вирішення проблем з фрагментацією пам'яті і підтримує надання спільного доступу до буферам за допомогою DMABUF .
2.Мережева підсистема
2.1. Додано новий планувальник пакетів PIE ( Proportional Integral controller Enhanced ), створений в рамках ініціативи щодо боротьби з негативним впливом проміжної буферизації пакетів ( Bufferbloat ) мережевим обладнанням. PIE дозволяє підтримувати на заданому рівні середню величину затримок для пакетів в черзі. У процесі оцінки ефективності роботи PIE було виявлено, що алгоритм здатний в забезпечити мінімальну затримку і високий рівень утилізації пропускної здатності линка при виникненні різних видів перевантаження.
2.2. Додана нова дисципліна організації роботи черг пакетів " heavy - hitter filter " ( HHF qdisc ) , яка намагається відокремлювати дрібні потоки від великих і поміщати великі потоки в окрему чергу з пониженням пріоритетом. Використання HHF дозволяє знизити вплив інтенсивних передач на критичні до затримок види трафіку .
2.3. Додана нова можливість " TCP autocorking ", що дозволяє затримати передачу невеликих порцій даних для об'єднання їх у більш великі пакети , що дозволяє знизити навантаження на CPU і забезпечити більш ефективну пропускну здатність. Для управління новою можливістю представлений sysctl tcp_autocorking . За замовчуванням підтримка tcp_autocorking включена .
2.4. Для підсистеми BPF ( Berkeley Packet Filter ) представлені дві нові утиліти , працюють у просторі користувача: відладчик і проста реалізація асемблера.
2.5. Додано новий ioctl виклик SIOCGHWTSTAMP , що дозволяє додаткам отримати поточну конфігурацію міток часу ( timestamping ) , без внесення до неї змін .
2.6. Покращена реалізація стека Bluetooth Low Energy : розширено кількість протоколів , який можуть використовуватися в режимі низького енергоспоживання Bluetooth , додана підтримка емуляції 6LoWPAN , забезпечена обробка прив'язаних до з'єднань каналів .
3.Віртуалізація та безпека
3.1. Інтегровані напрацювання проекту KASLR (аналог ASLR для ядра) з реалізацією засобів рандомізації розкладки адресного простору ядра , які дозволили збільшити стійкість ядра до деяких видів атак , що експлуатують вразливості в ядрі. KASLR вже успішно використовується для підвищення безпеки Chrome OS.
3.2. Забезпечена можливість збірки ядра з включенням поліпшеного режиму захисту від переповнення стека " - fstack - protector - strong " , який з'явиться в GCC 4.9 . Збірка в режимі " - fstack - protector - strong " дозволяє забезпечити захист від переповнення стека в більшому числі функцій ядра , утримавши при цьому пов'язані з додатковою перевіркою накладні витрати на прийнятному рівні.
3.3. У гіпервізор Xen додана підтримка режиму PVH для гостьових систем , який комбінує елементи режимів паравіртуалізації (PV ) і повної віртуалізації ( HVM ) . У режимі PVH з одного боку застосовується повна віртуалізація на рівні обмеження привілейованих інструкцій , ізоляції системних викликів і віртуалізації таблиць сторінок пам'яті , але з іншого боку використовуються методи паравіртуалізації для введення / виведення , обробки переривань , організації завантаження та взаємодії з обладнанням. Таким чином , PVH , як і режим PV , забезпечує високу продуктивність , завдяки виключенню накладних витрат на симуляцію апаратних пристроїв , але використовує замість PV MMU властиві HVM механізми апаратної віртуалізації для забезпечення більш суворої ізоляції віртуальних оточень .
3.4. При роботі на системах з архітектурою ARM додана підтримка забезпечення захисту від модифікації та виконання блоків text та інших даних в модулях ядра , помічених тільки на читання .
4. Апаратні архітектури
4.1. Додана підтримка родини багатопоточних багатоядерних 32 - розрядних процесорів interAptiv , побудованих на базі архітектури MIPS .
4.2. Для архітектури m68k забезпечена підтримка системного виклику kexec ( ) .
4.3. У гіпервізора Xen припинена підтримка архітектури ia64 .
4.4. Для архітектури AMD64 додана підтримка міток переходу ( jump labels ) та системи розподілу пам'яті CMA ( Contiguous Memory Allocator ) , яка оптимізована на виділення великих безперервних областей пам'яті з використанням техніки переміщення сторінок пам'яті.
4.5. Підтримка платформ Intel Clovertrail ( Atom Z2760 ) , що набула поширення на планшетних ПК під управлінням Windows , і Intel Merrifield MID ( Atom Z3480 ) , орієнтованої на смартфони. 4.6. У коді підтримки архітектури xtensa додана підтримка багатопроцесорних систем .
5. Обладнання
5.1. Підтримка перемикання відеорежимів в просторі користувача ( UMS ) в DRM- драйвері Intel i915 оголошена застарілою і буде видалена з працюючих на рівні ядра компонентів драйвера через рік. Доведена до стабільного стану підтримка графічної підсистеми процесорів на базі мікроархітектури Broadwell , яка прийде на зміну Haswell.
5.2. У DRM- модулі драйвера Nouveau додана підтримка GPU NVIDIA серії GK110 ( GeForce GTX 780 , GTX Titan ) і GK208 (GeForce 630 /640) .
5.3 У DRM- модулі драйвера Radeon додана підтримка динамічного управління живленням ( DPM ) для нових чіпів AMD , в драйвері RadeonSI додана підтримка UVD - декодерів GPU.
5.4. У драйвері vmwgfx , що дозволяє використовувати 2D/3D-акселерацію в гостьових Linux- системах , що працюють під управлінням продуктів віртуалізації VMware , забезпечена підтримка нового віртуального GPU ( SVGA2 Hardware Revision 11 ) .
5.5. Додана підтримка бездротових адаптерів на базі чіпів RealTek RTL8821AE і Marvell 8897 , Ethernet- адаптерів на базі чіпів Realtek RTL8153 і Intel XL710 X710 ( Virtual Function Ethernet ) , віртуальних InfiniBand - інтерфейсів Cisco ( Virtual Interface InfiniBand ) .
5.6. У Video4Linux додана підтримка контролерів web - камер SoC TI OMAP4 , FM- приймачів з Broadcom BCM2048 , Silicon Labs Si4713 FM і Thanko Raremono , DVB-S/S2 демодуляторів Montage M88DS3103 , тюнерів Montage M88TS2022 і сенсорів камери Samsung S5K5BAF .
5.7. Підтримка одночіпових платформ Marvell Berlin , Energy Micro EFM32 , MOXA ART , Freescale i.MX50 , Hisilicon Hi36xx/Hi37xx , Snapdragon 800 MSM8974 , Freescale TWR - P102x PowerPC і Motorola / Emerson MVME5100 .
5.8. Підтримка SDHCI -контролерів Arasan .
5.9. Підтримка криптографічних сопроцессоров AMD ( CCP ) і Freescale MXS DCP .
Linux 3.15 буде прокидатися в 7-12 разів швидше
Розробники з компанії Intel запропонували включити в ядро Linux 3.15 патч , який значно прискорює процес виходу системи з сну. На тестових системах патч показує прискорення в 7-12 разів.
Розробники оптимізували деякі процедури на рівні драйверів ATA і SCSI. Як видно на графіках , ефект досягнуто за рахунок оптимізації асинхронного виконання процесів . При цьому підвищується швидкість та догляду в сплячий режим , і виходу з нього. Драйвери тепер більш інтелектуально обробляють виклики з ядра Linux , ставлячи їх у чергу . Таким чином , система здається відновленній після сну , хоча деякі процеси все ще довантажуються з жорсткого диска.
На тестовому комп'ютері Intel Core i7-3960X (3,3 ГГц) з SATA-контролером Intel C600/X79 і шістьма підключеними накопичувачами (SSD, DVD-ROM і 4 HDD) швидкість відходу в сплячий режим скоротилася з 2479 до 2417 мс, а відновлення - з 11656 до 1110 мс, тобто в 10,5 разів.
На іншому комп'ютері з єдиним HDD перший показник зменшився з 1897 до 1728 мс, а другий - з 5416 до 448 мс, тобто в 12 разів.
Виявлення великої кількості вірусів для 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 дозволили збільшити надійність і швидкість його роботи. Додана утиліта командного рядка , що володіє широкою функціональністю . Продукт тепер має можливість сканування запущених процесів для знешкодження активних загроз.