Јуче смо овде на блогу објавили вести о Аиа, библиотека за стварање еБПФ управљачких програма у Русту и да је сврха овога створити сигурније управљачке програме или Проссимо пројекат за осигурање меморије Линук кернела са Рустом (два сјајна пројекта о којима ће бити много речи у наредних месеци).
И за кратко време забележене су разне рањивости у којима искористите грешке у еБПФ-у и да је то проблем у којем програмери кернела нису престали да раде и можда је Руст решење.
Разлог за додиривање ове теме је тај недавно је објављена вест коју су идентификовали "Друга" рањивост у Линук кернелу (ЦВЕ-КСНУМКС-КСНУМКС) фор заобилажење заштите од рањивости класе Спецтре, с обзиром да ово омогућава употребу еБПФ подсистема како би се могао одредити садржај меморије као резултат стварања услова за спекулације извршавања одређених операција.
Помиње се да је рањивост настаје услед грешака у верификатору који се користи за откривање грешака и неваљаних активности у БПФ програмима. Верификатор наводи могуће стазе извршавања кода, али занемарује све опције гранања које нису важеће са становишта семантике архитектуре скупа инструкција.
Приликом покретања БПФ програма, процесор може нетачно предвидети опције гранања које верификатор није узео у обзир и извршити их у спекулативном режиму.
На погођеним системима, непривилеговани БПФ програм може искористити ову рањивост за филтрирање садржаја произвољне меморије језгра (а тиме и све физичке меморије) кроз бочни канал.
Нпр приликом анализе операције „учитавања“, верификатор претпоставља да се у упутству користи регистар са адресом чија је вредност увек у наведеним границама, али нападач може створити услове под којим процесор ће шпекулативно покушати да изврши трговину са адресом која не испуњава услове за верификацију.
Напад Спецтре захтева присуство одређене скрипте у привилегованом коду, што доводи до спекулативног извршавања упутстава. Манипулирањем БПФ програма који се прослеђују на извршење, могуће је генерисати таква упутства у еБПФ-у и филтрирати садржај меморије језгра и произвољна подручја физичке меморије кроз бочне канале.
Поред тога, можете да означите напомену о утицају на перформансе имовине за заштиту од класе рањивости Спецтре.
Ова напомена сумира резултате рр (Рецорд анд Реплаи) оптимизација програма за отклањање грешака, коју је једном креирала Мозилла за отклањање грешака у Фирефок-у које се тешко понављају. Кеширање системских позива коришћених за верификацију постојања директоријума смањило је рад „рр извора“ за тест пројекат са 3 минута 19 секунди на 36 секунди.
Аутор оптимизације је одлучио да провери колико ће се променити перформансе након онемогућавања Спецтре заштите. Након покретања система са параметром «ублажавање = искључено», време извршавања «рр извора» без оптимизације било је 2 минута 5 секунди (1.6 пута брже), а са оптимизацијом 33 секунде (9% брже).
Знатижељно, онемогућавање Спецтре заштите не само да је смањило време рада кода нивоа језгра за 1.4 пута (од 2 мин 9с до 1 мин 32с), такође је преполовила време извршења у корисничком простору (са 1 мин 9 на 33 с), вероватно због смањења ефикасности ЦПУ кеш меморија и ТЛБ се ресетују када је омогућена Спецтре заштита.
Проблем се појавио од издавања језгра 4.15 и је фиксиран у облику закрпа, који тренутно још увек не стижу у све дистрибуције, па се препоручује корисницима да ових дана изврше одговарајућа ажурирања чим приме обавештења.
Si желите да сазнате више о томе, можете проверити детаље У следећем линку.