CET-IBT
CET-IBT - гэта адсочванне ўскосных галінаванняў, абарона патоку кіравання, якая правярае мэты адсочваных ускосных выклікаў і пераходаў. Яна аддзелена ад ценявых стэкаў CET.
Што вам трэба ведаць
CET-IBT - гэта адсочванне ўскосных галінаванняў, абарона патоку кіравання, якая правярае мэты адсочваных ускосных выклікаў і пераходаў. Яна аддзелена ад ценявых стэкаў CET.
Як гэта працуе
Калі адсочванне ўключана для адпаведнага асяроддзя выканання, ускосная перадача павінна трапляць на адпаведную кропкавую інструкцыю ENDBR у адпаведнасці з правіламі архітэктуры. Механізм выкарыстоўвае архітэктурны стан адсочвання і выклікае выключэнне абароны кіравання, калі кантракт парушаецца. Інструментаванне кампілятара і бінарнага файла з'яўляецца часткай разгортвання.
Дзе гэта карысна
Кампілятар можа пазначаць дапушчальныя месцы ўскоснага ўваходу ў бібліятэцы. АС і асяроддзе выканання павінны прымяняць сумяшчальнае ўключэнне і палітыку да кода, які выконваецца. Наяўнасць байтаў ENDBR у дызасемблеры сама па сабе не даказвае, што сістэма зараз забяспечвае выкананне IBT.
Як праверыць падтрымку і актыўнасць
CPUID.07H.00H:EDX біт 20 пералічвае магчымасць IBT. Правярайце падтрымку карыстальніка/супервізара ў АС і бінарную палітыку асобна. Дыягнастуйце сумяшчальнасць, выкарыстоўваючы афіцыйныя інструкцыі па кампілятары і АС, замест таго каб выдаляць кропкавыя інструкцыі з бінарнага файла.
Магчымасць, уключэнне і прымяненне павінны правярацца асобна. Працэсар можа падтрымліваць абарону, у той час як АС, праграма або палітыка віртуальнай машыны яе не актывуюць. Поле падтрымкі ў базе даных не з'яўляецца атэстацыяй працуючай сістэмы.
Чаго гэта функцыя не гарантуе
IBT не правярае звычайныя вяртанні з функцый так, як гэта робяць ценявыя стэкі. Гэта не з'яўляецца гарантыяй поўнай цэласнасці патоку кіравання або бяспекі праграмы, і падтрымка ценявых стэкаў не пацвярджае падтрымку IBT.
Сумяшчальнасць і прадукцыйнасць на практыцы
Падтрымлівайце АС, мікрапраграму і адпаведнае асяроддзе выканання ў актуальным стане. Калі ахоўны механізм выклікае праблему сумяшчальнасці, спачатку скарыстайцеся дыягностыкай вытворцы і падтрымліваемымі абнаўленнямі. Агульнае пераключэнне параметраў абароны можа паўплываць на незвязаныя праграмы і павінна ажыццяўляцца згодна з выразнымі палітыкамі разгортвання і аднаўлення.
Практычны чэк-ліст для праверкі
- Зафіксуйце дакладную мадэль працэсара або платформы, а таксама задзейнічаныя версіі праграмы, АС і асяроддзя выканання. Захавайце дакладную фармулёўку памылкі або патрабавання.
- Звярніцеся да дакументацыі вытворцы для гэтай канкрэтнай мадэлі, затым праверце фактычныя магчымасці і ўключаны стан у асяроддзі, дзе выконваецца праграма.
- Супастаўце кожнае патрабаванне выбранага выканальнага файла або бэкэнда. Аналагічнай назвы функцыі, псеўданіма або агульнай назвы тэхналогіі недастаткова.
- Пацвердзіце, што праграма выбрала патрэбную рэалізацыю. Выкарыстоўвайце яе задакументаваныя сродкі дыягностыкі і падтрымліваемы запасны варыянт, калі патрабаванні не выконваюцца.
- Уносьце па адным падтрымліваемым змяненні за раз і паўтарайце тую ж нагрузку. Захоўвайце зыходную канфігурацыю і магчымасць адкату.
Калі функцыя пазначана, але праграмнае забеспячэнне не можа яе выкарыстоўваць
Пачніце з канкрэтнага кампанента, які выклікае збой. Апаратная база даных апісвае зафіксаваныя магчымасці; аперацыйная сістэма або гіпервізар могуць прадастаўляць іншае фактычнае асяроддзе. Памылка недапушчальнай інструкцыі (illegal instruction) таксама патрабуе даследавання канкрэтнай інструкцыі, якая выклікала збой, і зборкі бінарнага файла, паколькі пашкоджанне даных або іншая непадтрымліваемая інструкцыя могуць выклікаць аналагічны сімптом.
Усталюйце версію праграмы, драйвера або асяроддзя выканання, якая падтрымліваецца для дадзенай платформы, і пры неабходнасці выкарыстоўвайце задакументаваную вытворцам базавую або запасную зборку. Абнаўленне ПЗ не можа стварыць інструкцыю, якой няма ў працэсары. Змяненні ў мікрапраграме (firmware) і палітыках бяспекі павінны адпавядаць працэдурам вытворцы сістэмы і плану аднаўлення, а не агульным рэцэптам аптымізацыі.
Крыніцы і межы прымянення гэтага тлумачэння
Intel 64 and IA-32 Architectures Software Developer's Manual · Ядро Linux: ценявы стэк Control-flow Enforcement Technology
Гэтыя даведнікі вызначаюць архітэктурныя паводзіны і патрабаванні да праграмнага забеспячэння. Яны не пацвярджаюць незалежна кожнае значэнне функцыі на звязанай старонцы мадэлі абсталявання. Для праверкі падтрымкі мадэллю выкарыстоўвайце даныя вытворцы на адпаведнай старонцы і правярайце фактычную канфігурацыю сістэмы. Гэты артыкул не змяшчае вынікаў тэсціравання (benchmark), сертыфікацыі або даты незалежнага агляду.
Крыніцы і праверка
Рэдакцыйная прыналежнасць: Feex. Дата незалежнай праверкі не зафіксавана. Як мы даследуем.
- Intel 64 and IA-32 Architectures Software Developer's Manual · Тамы 1 і 2 апісваюць названыя сямействы інструкцый і CPUID; Том 3 апісвае стан, старонкавую арганізацыю памяці, VMX і элементы кіравання абаронай. Архітэктурная дакументацыя не пацвярджае падтрымку канкрэтнай мадэлі.
- Ядро Linux: ценявы стэк Control-flow Enforcement Technology · Адрознівае апаратную падтрымку, бінарныя маркеры, уключэнне загрузчыкам і актыўную абарону для асобных патокаў. Апісвае IBT і ценявыя стэкі як асобныя сродкі.
Ці быў гэты артыкул карысным?
Дастаткова адказаць "так" або "не". Выберыце прычыну, калі хочаце, або дадайце кароткую нататку.
Дзякуй. Гэта дапамагае нам паляпшаць гэтую старонку.