Інжынер Google прапанаваў праграмную абарону працэсараў ад нападу тыпу LVI.

Некаторы час таму стала вядома аб новай уразлівасці спекулятыўнай архітэктуры працэсараў Intel, якую назвалі Load Value Injection (LVI). У кампаніі Intel ёсць сваё меркаванне аб небяспецы LVI і рэкамендацыі па яе змякчэнні. Свой варыянт абароны ад падобных нападаў прапанаваў інжынер кампаніі Google. Але за бяспеку давядзецца расплаціцца зніжэннем прадукцыйнасці працэсара ў сярэднім на 7%.

Інжынер Google прапанаваў праграмную абарону працэсараў ад нападу тыпу LVI.

Раней мы адзначалі, што небяспека LVI крыецца не ў канкрэтным механізме, выяўленым даследнікамі, а ў самім прынцыпе LVI-напады па пабочных каналах, які быў паказаны ўпершыню. Тым самым быў адкрыты новы напрамак для пагроз, пра якія раней ніхто не падазраваў (ва ўсякім разе, пра гэта не гаварылася ў публічнай прасторы). Таму каштоўнасць распрацоўкі адмыслоўца Google Золя Брыджэрса (Zola Bridges) складаецца ў тым, што яго латка змякчае небяспеку яшчэ нават невядомых новых нападаў па прынцыпе LVI.

Раней у асэмблер праекта GNU (Асамблер GNU) былі ўнесены змены, якія зніжалі небяспеку ўразлівасці LVI. Гэтыя змены складаліся ў даданні бар'ерных інструкцый LFENCE, якія ўстанаўлівалі строгую паслядоўнасць паміж зваротамі да памяці да і пасля бар'ера. Тэставанне патча на адным з працэсараў Intel пакалення Kaby Lake паказала зніжэнне прадукцыйнасці да 22%.

Распрацоўнік Google прапанаваў свой патч з даданнем інструкцый LFENCE у набор кампілятараў LLVM, а абарону назваў SESES (Speculative Execution Side Effect Suppression). Прапанаваны ім варыянт абароны змякчае як пагрозы LVI, так і іншыя падобныя, напрыклад, Spectre V1/V4. Рэалізацыя SESES дае магчымасць кампілятару дадаваць інструкцыі LFENCE у патрэбных месцах падчас генерацыі машыннага кода. Напрыклад, падстаўляць іх перад кожнай інструкцыяй чытання з памяці ці запісы ў памяць.

Інструкцыі LFENCE забараняюць папераджальнае выкананне ўсіх наступных інструкцый, пакуль папярэднія аперацыі чытання з памяці не будуць завершаны. Відавочна, што гэта ўплывае на прадукцыйнасць працэсараў. Даследчык высветліў, што ў сярэднім абарона SESES зніжала хуткасць выканання задач з выкарыстаннем абароненай бібліятэкі на 7,1%. Роскід зніжэння прадукцыйнасці пры гэтым складаў ад 4 да 23%. Першапачатковы прагноз даследчыкаў быў больш песімістычны, мяркуючы зніжэнне прадукцыйнасці да 19 разоў.



Крыніца: 3dnews.ru

Дадаць каментар