Задните врати в микрокода на x86 процесорните инструкции
Ние от дълго време не имаме вяра на софтуера и това е повода за неговата непрекъсната инспекция, назад инженерство, дизасемблиране, тестване във виртуални машини и така нататък А какво да кажем за процесора, който извършва този програмен продукт? Ние сляпо и безрезервно имаме вяра на този дребен пай от силиций. Само че актуалният хардуер има същите проблеми, каквито има и софтуера: секрети недокументирани функционалности, неточности, уязвимости, малуер, троянци, рууткити, задни порти. Да се спрем по-подробно.
ISA (Instruction Set Architecture) на х86 архитектурата е един непрестанно изменящ се комплект от процесорни команди. Започвайки от дизайна на 8086, създаден през 1976 година, ISA претърпя и търпи непрекъснати промени и обновявания. Но през цялото това време се резервира противоположната съгласуемост и поддръжката на истинските спецификации. За 40 години порастване, ISA инструкциите станаха извънредно доста, като не престават да излизат нови режими и нови указания, всяка от които прибавя към предходния дизайн от машинни команди нов пласт. Поради политиката на цялостна противоположна съгласуемост, в актуалните х86 процесори участват даже и указания и режими, които към сегашен ден са изцяло забравени. В последна сметkа, резултатът е процесорна архитектура, която е същински лабиринт от нови и антикварни машинни указания. Тази прекомерно комплицирана среда поражда редица проблеми с кибербезопасността на процесора. Ето за какво, х86 процесорите не могат да претендират за ролята на доверени чипове на една сериозно значима киберинфраструктура.
Още ли вярвате на своя процесор?
Безопасността на стратегиите и операционната система се базира на сигурността на хардуера, на който са стартирани. Обикновено разработчиците и програмистите не се замислят над обстоятелството, че процесорът, на който ще бъде употребен техния програмен продукт, може да бъде обезсърчителен и да има редица бъгове. Когато хардуерът позволява неточности (умишлено или не), софтуерните механизми за обезпечаване на сигурността стават безсмислени. От доста години се оферират разнообразни модели на особено предпазени процесори: Intel SGX, AMD Pacifica и други. Но все пак, най-редовно се появява информация за сериозни хардуерни неточности – да си напомним Meltdown и Spectre. Нещо повече, честото разкриване на недокументирани указания „за премахване на грешки“, навеждат на мисълта, че сляпото доверие към процесорите е напълно безпочвено.
Съвременните х86 процесори са едно гигантско и комплицирано преплитане на най-новите и на антикварните технологии. Да си напомним, че 8086 има 29 000 транзистори, Pentium е към този момент с 3 милиона, Broadwell процесорите имат 3,2 милиарда, а Cannonlake трансферираха 10 милиарда.
При толкоз доста транзистори, не е за удивление, че актуалните х86 процесори са цялостни с недокументирани указания и хардуерни уязвимости. Ето някои от тези недокументирани указания: ICEBP (0xF1), LOADALL (0x0F07), apicall (0x0FFFF0), даващи опция за разблокиране на процесора за несанкциониран достъп до предпазените области от паметта.
Що се отнася до многочислените хардуерни уязвимости (двете изображения по-надолу), то те дават на хакерите опция за повишение на привилегиите, добиване на криптографските ключове, основаване на нови процесорни указания, смяна на функционалността на към този момент съществуващите процесорни указания, слагането на спирания на инструкциите, вдишване на контрола върху хардуерната виртуализация, проникване в „атомарните криптографски изчисления“. Най-сладкото е за най-после – „Божествен режим“ в Intel ME : подсигуряването на хардуерен бъг даже и в изключен компютър. И всичко това без да се оставят цифрови следи.
#td_uid_41_5bd32135ce572.td-doubleSlider-2.td-item1{background:url(https://i1.wp.com/www.kaldata.com/wp-content/uploads/2018/10/30.png?resize=80%2C60&ssl=1) 0 0 no-repeat}#td_uid_41_5bd32135ce572.td-doubleSlider-2.td-item2{background:url(https://i0.wp.com/www.kaldata.com/wp-content/uploads/2018/10/31-1.png?resize=80%2C60&ssl=1) 0 0 no-repeat}1 от 2
Да напомним в резюме, че Intel Management Engine (Intel ME) е самостоятелна подсистема, вграждана съвсем всички процесори на Intel от 2008 година до сегашен ден. Тъй като чипът постоянно получава напрежение от вградената дребна акумулаторна батерия или от различен източник, Intel ME продължава да работи и когато компютърът е изключен. Intel твърди, че тази система е нужна за обезпечаване на оптималната продуктивност. Intel ME се пази в най-строга загадка. Точният принцип на работа не е документиран, а кодът е обфускиран (маскиран) посредством код на Хъфман, таблицата на който се съхранява в самия чип и липсва информация за декодирането.
Съвременните процесори са повече програмен продукт, в сравнение с хардуер
Строго видяно, актуалните процесори даже не могат да бъдат наречени „хардуер“ в цялостния смисъл на тази дума. Защото тяхната най-критична функционалност (включително ISA) се обезпечава от микрокод, който постоянно се обновява. Първоначално, микрокодът се използваше за декодиране и осъществяване на комплицираните процесорни указания: интервенциите с плаваща запетая, MMX примитивите, инструкциите за работа със низове REP и така нататък Но с течение на времето, на микрокода започнаха да се разпореждат от ден на ден отговорности за обработката на вътрешните процеси в чиповете. Така да вземем за пример, актуалните разширени указания за процесорите на Intel, като да вземем за пример AVX (Advanced Vector Extensions) и VT-d (хардуерната виртуализация) са напълно осъществени благодарение на микрокод.
Освен това, към сегашен ден микрокодът е виновен и за опазване положението на процесора, за ръководството на кеша и потреблението на електрическа сила. Специално за икономичните режими на процесора е осъществен механизъм на спирания, обработващ положенията на режимите на консумация. С-състоянието (степента на хибернация), Р-състоянието (различните комбинации на волтажа и честотата) – всичко е микрокод. Обнуляването на L2 кеша при влизане в С4 положението, както и излизането от това положение – също е работа на микрокода.
Защо производителите на процесори употребяват микрокод?
В х86 процесорите микрокодът се употребява за разлагането на комплицираните процесорни указания, дължината на които от време на време доближава 15 байта, във верига от опростени микроинструкции. По този метод доста се облекчава хардуерната архитектура и се облекчава диагностиката. На процедура, това е тълковник сред външната забележима за потребителя CISC архитектура и вътрешната хардуерна RISC архитектура.
При разкриване на неточност в CISC архитектурата (преди всичко в ISA), производителят разгласява възобновяване на микрокода, което може да се зареди посредством BIOS/UEFI на дънната платка или посредством операционната система по време на нейното зареждане. Благодарение на тази система от обновявания, основана на микрокодове, процесорните производители си обезпечават еластичност и понижаване на разноските при оправяне на грешките в своите чипове.
Нашумялата неточност с fdiv, която по този начин зле се отрази на процесорите Intel Pentium през 1994 година доста ясно сподели, че във високотехнологичния хардуер има неточности напълно като в софтуера. Този случай провокира още по-голям интерес към архитектурите на процесори, основани на микрокодове. Ето за какво Intel и AMD напълно минаха към микрокодове. Intel през 1995 година с излизането на Pentium Pro (P6) и AMD през 1999 година със своя K7.
Всичко скрито става очевидно
Въпреки че процесорните производители държат архитектурата на микрокодовете и механизма на тяхното възобновяване в най-строга загадка, от време на време излиза нещо. Частички информация (основно от патентите, да вземем за пример AMD RISC86, и деликатно дизасемблиране на формалните обновявания за BIOS, последователно проливат светлина върху тайните на микрокода. Това не е доста добре. Благодарение на непрекъснатото рационализиране на дизасемблирането благодарение на хардуерни средства, новите способи на фазинг, и появяването на OpenSource принадлежности като Microparse и Sandsifter, хакерът може да разбере всичко належащо, с цел да напише малуер на микрокод.
Така да вземем за пример, на микрокод към този момент е основано спиране, които може да прихваща една процесорна директива и да пресмята, какъв брой пъти процесорът е употребявал командата div. Това в действителност е инжектиране на микрокод в микрокода за осъществяване на процесорната директива div. Примерът е даден единствено с образователни цели.
Има по-усъвършенствани кодове от сходен вид, които си остават в процесорната директива и по никакъв метод не издават своето наличие. Следващият образователен образец демонстрира, че този сегмент от микрокода се задейства единствено когато при осъществяване на div ebx се извършват съответни условия: регистърът ebx има смисъла B, а в регистъра eax е със значение А. При активиране, този сегмент усилва смисъла на регистъра eip (указателя на инструкциите) с единица. Ако някоя стратегия въпреки всичко се натъкне на променената директива div ebx и изискванията се изпълнят, осъществяването на машинния код ще се трансферира към идващия след div ebx байт. Ако в eax и ebx са сложени някакви други цифри, div ebx ще се извърши обикновено.
За какво е нужно това? По този метод е допустимо да се задейства скрита верига процесорни указания, като преходът към нея няма по какъв начин да се открие. Това е метод за основаване на напълно неразгадаеми машинни стратегии, при които общоприетите указания по незнаен за потребителя метод извършват нещо напълно друго, за което той изобщо не подозира.
Тези два образеца показват опцията в най-обикновените и общоприети процесорни указания да се вмъкне случаен троянски код. Разбира се, написан на микрокод.
И още, хакерът може да задейства своя нездравословен код отдалечено. Например, когато изискването за активиране на вредоносния сегмент се сложи в уеб страница, следена от злоумишленика. Това е допустимо с помощта на компилаторите Just-in-Time (JIT) и Ahead-of-Time (AOT), вградени в актуалните браузъри. Тези компилатори, сходно на доста други, могат да вмъкват процесорни указания в езиците от високо равнище – да вземем за пример, JavaScript.
ISA (Instruction Set Architecture) на х86 архитектурата е един непрестанно изменящ се комплект от процесорни команди. Започвайки от дизайна на 8086, създаден през 1976 година, ISA претърпя и търпи непрекъснати промени и обновявания. Но през цялото това време се резервира противоположната съгласуемост и поддръжката на истинските спецификации. За 40 години порастване, ISA инструкциите станаха извънредно доста, като не престават да излизат нови режими и нови указания, всяка от които прибавя към предходния дизайн от машинни команди нов пласт. Поради политиката на цялостна противоположна съгласуемост, в актуалните х86 процесори участват даже и указания и режими, които към сегашен ден са изцяло забравени. В последна сметkа, резултатът е процесорна архитектура, която е същински лабиринт от нови и антикварни машинни указания. Тази прекомерно комплицирана среда поражда редица проблеми с кибербезопасността на процесора. Ето за какво, х86 процесорите не могат да претендират за ролята на доверени чипове на една сериозно значима киберинфраструктура.
Още ли вярвате на своя процесор?
Безопасността на стратегиите и операционната система се базира на сигурността на хардуера, на който са стартирани. Обикновено разработчиците и програмистите не се замислят над обстоятелството, че процесорът, на който ще бъде употребен техния програмен продукт, може да бъде обезсърчителен и да има редица бъгове. Когато хардуерът позволява неточности (умишлено или не), софтуерните механизми за обезпечаване на сигурността стават безсмислени. От доста години се оферират разнообразни модели на особено предпазени процесори: Intel SGX, AMD Pacifica и други. Но все пак, най-редовно се появява информация за сериозни хардуерни неточности – да си напомним Meltdown и Spectre. Нещо повече, честото разкриване на недокументирани указания „за премахване на грешки“, навеждат на мисълта, че сляпото доверие към процесорите е напълно безпочвено.
Съвременните х86 процесори са едно гигантско и комплицирано преплитане на най-новите и на антикварните технологии. Да си напомним, че 8086 има 29 000 транзистори, Pentium е към този момент с 3 милиона, Broadwell процесорите имат 3,2 милиарда, а Cannonlake трансферираха 10 милиарда.
При толкоз доста транзистори, не е за удивление, че актуалните х86 процесори са цялостни с недокументирани указания и хардуерни уязвимости. Ето някои от тези недокументирани указания: ICEBP (0xF1), LOADALL (0x0F07), apicall (0x0FFFF0), даващи опция за разблокиране на процесора за несанкциониран достъп до предпазените области от паметта.
Що се отнася до многочислените хардуерни уязвимости (двете изображения по-надолу), то те дават на хакерите опция за повишение на привилегиите, добиване на криптографските ключове, основаване на нови процесорни указания, смяна на функционалността на към този момент съществуващите процесорни указания, слагането на спирания на инструкциите, вдишване на контрола върху хардуерната виртуализация, проникване в „атомарните криптографски изчисления“. Най-сладкото е за най-после – „Божествен режим“ в Intel ME : подсигуряването на хардуерен бъг даже и в изключен компютър. И всичко това без да се оставят цифрови следи.
#td_uid_41_5bd32135ce572.td-doubleSlider-2.td-item1{background:url(https://i1.wp.com/www.kaldata.com/wp-content/uploads/2018/10/30.png?resize=80%2C60&ssl=1) 0 0 no-repeat}#td_uid_41_5bd32135ce572.td-doubleSlider-2.td-item2{background:url(https://i0.wp.com/www.kaldata.com/wp-content/uploads/2018/10/31-1.png?resize=80%2C60&ssl=1) 0 0 no-repeat}1 от 2
Да напомним в резюме, че Intel Management Engine (Intel ME) е самостоятелна подсистема, вграждана съвсем всички процесори на Intel от 2008 година до сегашен ден. Тъй като чипът постоянно получава напрежение от вградената дребна акумулаторна батерия или от различен източник, Intel ME продължава да работи и когато компютърът е изключен. Intel твърди, че тази система е нужна за обезпечаване на оптималната продуктивност. Intel ME се пази в най-строга загадка. Точният принцип на работа не е документиран, а кодът е обфускиран (маскиран) посредством код на Хъфман, таблицата на който се съхранява в самия чип и липсва информация за декодирането.
Съвременните процесори са повече програмен продукт, в сравнение с хардуер
Строго видяно, актуалните процесори даже не могат да бъдат наречени „хардуер“ в цялостния смисъл на тази дума. Защото тяхната най-критична функционалност (включително ISA) се обезпечава от микрокод, който постоянно се обновява. Първоначално, микрокодът се използваше за декодиране и осъществяване на комплицираните процесорни указания: интервенциите с плаваща запетая, MMX примитивите, инструкциите за работа със низове REP и така нататък Но с течение на времето, на микрокода започнаха да се разпореждат от ден на ден отговорности за обработката на вътрешните процеси в чиповете. Така да вземем за пример, актуалните разширени указания за процесорите на Intel, като да вземем за пример AVX (Advanced Vector Extensions) и VT-d (хардуерната виртуализация) са напълно осъществени благодарение на микрокод.
Освен това, към сегашен ден микрокодът е виновен и за опазване положението на процесора, за ръководството на кеша и потреблението на електрическа сила. Специално за икономичните режими на процесора е осъществен механизъм на спирания, обработващ положенията на режимите на консумация. С-състоянието (степента на хибернация), Р-състоянието (различните комбинации на волтажа и честотата) – всичко е микрокод. Обнуляването на L2 кеша при влизане в С4 положението, както и излизането от това положение – също е работа на микрокода.
Защо производителите на процесори употребяват микрокод?
В х86 процесорите микрокодът се употребява за разлагането на комплицираните процесорни указания, дължината на които от време на време доближава 15 байта, във верига от опростени микроинструкции. По този метод доста се облекчава хардуерната архитектура и се облекчава диагностиката. На процедура, това е тълковник сред външната забележима за потребителя CISC архитектура и вътрешната хардуерна RISC архитектура.
При разкриване на неточност в CISC архитектурата (преди всичко в ISA), производителят разгласява възобновяване на микрокода, което може да се зареди посредством BIOS/UEFI на дънната платка или посредством операционната система по време на нейното зареждане. Благодарение на тази система от обновявания, основана на микрокодове, процесорните производители си обезпечават еластичност и понижаване на разноските при оправяне на грешките в своите чипове.
Нашумялата неточност с fdiv, която по този начин зле се отрази на процесорите Intel Pentium през 1994 година доста ясно сподели, че във високотехнологичния хардуер има неточности напълно като в софтуера. Този случай провокира още по-голям интерес към архитектурите на процесори, основани на микрокодове. Ето за какво Intel и AMD напълно минаха към микрокодове. Intel през 1995 година с излизането на Pentium Pro (P6) и AMD през 1999 година със своя K7.
Всичко скрито става очевидно
Въпреки че процесорните производители държат архитектурата на микрокодовете и механизма на тяхното възобновяване в най-строга загадка, от време на време излиза нещо. Частички информация (основно от патентите, да вземем за пример AMD RISC86, и деликатно дизасемблиране на формалните обновявания за BIOS, последователно проливат светлина върху тайните на микрокода. Това не е доста добре. Благодарение на непрекъснатото рационализиране на дизасемблирането благодарение на хардуерни средства, новите способи на фазинг, и появяването на OpenSource принадлежности като Microparse и Sandsifter, хакерът може да разбере всичко належащо, с цел да напише малуер на микрокод.
Така да вземем за пример, на микрокод към този момент е основано спиране, които може да прихваща една процесорна директива и да пресмята, какъв брой пъти процесорът е употребявал командата div. Това в действителност е инжектиране на микрокод в микрокода за осъществяване на процесорната директива div. Примерът е даден единствено с образователни цели.
Има по-усъвършенствани кодове от сходен вид, които си остават в процесорната директива и по никакъв метод не издават своето наличие. Следващият образователен образец демонстрира, че този сегмент от микрокода се задейства единствено когато при осъществяване на div ebx се извършват съответни условия: регистърът ebx има смисъла B, а в регистъра eax е със значение А. При активиране, този сегмент усилва смисъла на регистъра eip (указателя на инструкциите) с единица. Ако някоя стратегия въпреки всичко се натъкне на променената директива div ebx и изискванията се изпълнят, осъществяването на машинния код ще се трансферира към идващия след div ebx байт. Ако в eax и ebx са сложени някакви други цифри, div ebx ще се извърши обикновено.
За какво е нужно това? По този метод е допустимо да се задейства скрита верига процесорни указания, като преходът към нея няма по какъв начин да се открие. Това е метод за основаване на напълно неразгадаеми машинни стратегии, при които общоприетите указания по незнаен за потребителя метод извършват нещо напълно друго, за което той изобщо не подозира.
Тези два образеца показват опцията в най-обикновените и общоприети процесорни указания да се вмъкне случаен троянски код. Разбира се, написан на микрокод.
И още, хакерът може да задейства своя нездравословен код отдалечено. Например, когато изискването за активиране на вредоносния сегмент се сложи в уеб страница, следена от злоумишленика. Това е допустимо с помощта на компилаторите Just-in-Time (JIT) и Ahead-of-Time (AOT), вградени в актуалните браузъри. Тези компилатори, сходно на доста други, могат да вмъкват процесорни указания в езиците от високо равнище – да вземем за пример, JavaScript.
Източник: kaldata.com
КОМЕНТАРИ