Ако сте забринути за интегритет вашег система, dm-verity је један од кључних делова Линукс екосистема. да би се безбедно покренуо систем и открила неовлашћена измена меморије. Настао је као део мапера уређаја језгра и сада је основа за верификовано покретање у Андроиду, ОпенВрт-у и дистрибуцијама које траже побољшану безбедност.
Далеко од тога да је апстрактни појам, dm-verity се конфигурише и користи са правим алатима као што су veritysetup и systemd-veritysetupВалидира блокове у ходу користећи хеш стабла и може реаговати на оштећења политикама које се крећу од евидентирања догађаја до поновног покретања или рушења система. Хајде да погледамо детаљније, без остављања нерешених питања.
Шта је dm-verity и зашто би вас то могло занимати
dm-verity је циљ мапирања уређаја у језгру који проверава интегритет блок уређаја док се подаци читајуРади тако што израчунава и проверава хешеве сваког блока (обично 4K) у односу на унапред израчунато хеш стабло, обично користећи SHA-256.
Овај дизајн омогућава Датотеке се не могу тихо мењати између поновног покретања система или током извршавањаКључно је за проширење ланца поверења у покретању система на оперативни систем, ограничавање постојаности злонамерног софтвера, јачање безбедносних политика и обезбеђивање шифровања и MAC механизама током покретања.
На Андроиду (од верзије 4.4) и Линуксу уопште, Поверење је усидрено у коренском хешу стабла, који је потписан и валидиран јавним кључем који се налази на заштићеној локацији (нпр. на партицији за покретање или у UKI-ју потписаном помоћу Secure Boot-а). Разбијање било ког блока захтевало би разбијање основног криптографског хеша.
Верификација се врши блоковски и на захтев: Додата латенција је минимална у поређењу са трошковима I/O операција.Ако провера не успе, језгро враћа И/О грешку и систем датотека изгледа оштећено, што се очекује када су подаци непоуздани. Апликације могу да одлуче да ли ће наставити или не на основу своје толеранције на грешке.
Како стабло верификације функционише интерно
Стабло верификације је изграђено у слојевима. Слој 0 су сирови подаци са уређаја, подељени на блокове од 4K; SHA-256 (засољени) хеш се израчунава за сваки блок. Ови хешеви се затим спајају да би се формирао слој 1. Слој 1 се затим групише у блокове и поново хешира да би се формирао слој 2, и тако даље док се све не уклопи у један блок: тај блок, када се хешира, производи коренски хеш.
Ако било који слој не употпуњује тачно блок, Допуњује се нулама док не достигне 4K да би се избегла двосмисленост. Укупна величина стабла зависи од величине партиције која се проверава; у пракси је обично мања од 30 MB за типичне системске партиције.
Општи процес је: изаберите случајну сол, хеширајте на 4K, израчунајте SHA-256 са солом по блоку, спаја се да би формирао нивое, допуњава границу блока нулама и понавља се са претходним нивоом док не остане један коренски хеш. Тај коренски хеш, заједно са коришћеном соли, доставља dm-verity табелу и потпис.
Верзије формата диска и алгоритам
Формат хеш блокова на диску има верзију. Верзија 0 је била оригинална верзија која се користила у Chromium OS-у.Со се додаје на крају процеса хеширања, дајџести се чувају континуирано, а остатак блока се допуњава нулама.
La Верзија 1 се препоручује за нове уређајеСо се додаје на почетак хеша, а сваки дајџ је допуњен нулама до степена два, побољшавајући поравнање и робусност. dm-verity табела такође одређује алгоритам (нпр. sha1 или sha256), иако се за тренутну безбедност користи sha256.
dm-verity табела и основни параметри
Циљна табела коју dm-verity описује где су подаци, где је хеш стабло и како то проверитиТипична поља табеле:
- девуређај са подацима који треба да се верификују (тип путање /dev/sdXN или већи:мањи).
- хеш_развој: уређај са хеш стаблом (може бити исти; ако је тако, hash_start мора бити ван означеног опсега).
- величина_блока_података: величина блока података у бајтовима (нпр. 4096).
- величина_хеш_блока: величина хеш блока у бајтовима.
- број_блокова_података: број проверљивих блокова података.
- хеш_почетни_блок: помак (у блоковима hash_block_size) у односу на коренски блок стабла.
- алгоритам: хеш алгоритам (нпр. sha256).
- дигестхексадецимално кодирање хеша коренског блока (укључујући „сол“ према верзији формата); овој вредности треба веровати.
- сохексадецимална со.
Поред тога, постоје опциони параметри веома корисно за прилагођавање понашања:
- игнориши_корупцију: Снима оштећене блокове, али дозвољава наставак читања.
- поновно_покретање_при_корупцији: поново покрени након детекције оштећења (није компатибилно са ignore_corruption и захтева подршку корисничког простора да би се избегле петље).
- паника_због_корупције: : изазива панику при откривању корупције (није компатибилно са претходним верзијама).
- поново_покрени_при_грешци y паника_при_грешциисте реакције, али за I/O грешке.
- игнориши_нула_блокова: не проверава блокове који се очекују као нуле и враћа нуле.
- коришћење_фек_са_уређаја + fec_roots + фец_блокови + fec_startОмогућите Рид-Соломонову (FEC) технологију да опорави податке када верификација не успе; области података, хеша и FEC-а не смеју се преклапати, а величине блокова морају се подударати.
- провери_највише_једномПроверава сваки блок података само први пут када се чита (смањује оптерећење на штету безбедности код активних напада).
- опис_кључа_потписа_root_hashРеференца на кључ у привеску кључева за валидацију PKCS7 потписа коренског хеша приликом креирања мапирања (захтева одговарајућу конфигурацију језгра и поуздане привеске кључева).
- try_verify_in_taskletАко су хешеви кеширани и величина У/И дозвољава, проверава се доња половине да би се смањила латенција; подешава се са /sys/module/dm_verity/parameters/use_bh_bytes по У/И класи.
Потпис, метаподаци и усидрење поверења
Да би dm-verity био поуздан, Коренски хеш мора бити поуздан и обично потписанУ класичном Андроиду, јавни кључ је укључен у партицију за покретање, коју екстерно верификује произвођач; он валидира потпис коренског хеша и осигурава да системска партиција није измењена.
Метаподаци Verity-ја додају структуру и контролу верзија. Блок метаподатака садржи магични број 0xb001b001 (бајтови b0 01 b0 01), верзија (тренутно 0), потпис табеле у PKCS1.5 (типично 256 бајтова за RSA-2048), дужина табеле, сама табела и нула попуњавање до 32K.
У Андроид имплементацијама, верификација се ослања на fs_mgr и fstabДодавање ознаке за потврду одговарајућем уносу и стављање кључа у /boot/verity_key. Ако магични број није тамо где треба да буде, верификација се зауставља како би се избегла провера погрешне ствари.
Почетак операције верификован
Заштита се налази у језгру: Ако је угрожено пре покретања језгра, нападач задржава контролуЗато произвођачи обично строго валидирају сваку фазу: кључ уграђен у уређај верификује први покретачки програм, који верификује следећи, покретачки програм апликације, и на крају, језгро.
Са верификованим кернелом, dm-verity је омогућен приликом монтирања верификованог блок уређајаУместо хеширања целог уређаја (што би било споро и трошило енергију), он се верификује блок по блок док му се приступа. Квар узрокује I/O грешку, а сервиси и апликације реагују у складу са својом толеранцијом: или настављају без тих података или се потпуно срушавају.
Форвард корекција грешака (FEC)
Од Андроида 7.0, FEC (Reed-Solomon) је инкорпориран са техникама испреплитања да би се смањио простор и повећала могућност опоравка оштећених блокова. Ово функционише заједно са dm-verity: ако провера не успе, подсистем може покушати да је исправи пре него што је прогласи неопорављивом.
Перформансе и оптимизација
Да бисте смањили утицај: Омогућите SHA-2 убрзање помоћу NEON-а на ARMv7 и SHA-2 екстензија на ARMv8 из језгра. Прилагодите параметре за унапред читање и prefetch_cluster за ваш хардвер; верификација по блоку обично мало доприноси трошковима улазно/излазних операција, али ова подешавања праве разлику.
Почетак рада на Линуксу (systemd, veritysetup) и Андроиду
На модерном Линуксу са systemd-ом, dm-verity омогућава верификовани root само за читање користећи veritysetup (део cryptsetup-а), systemd-veritysetup.generator и systemd-veritysetup@.service. Препоручује се укључивање Secure Boot-а и потписаног UKI-ја (уједињене слике језгра), иако нису строго обавезни.
Припрема и препоручено партиционисање
Део функционалног и прилагођеног система. Резервишите запремину за хеш стабло (8–10% величине кореновог директоријума је обично довољно) и размислите о одвајању /home и /var ако је потребно да пишете. Типична шема укључује: ESP (за покретачки програм), XBOOTLDR (за UKI), root (са или без енкрипције), VERITY партицију и опционо /home и /var.
Као корен, EROFS је веома занимљива алтернатива за ext4 или squashfsДизајниран је само за читање, са веома добрим перформансама на флеш/SSD меморији, lz4 компресијом по подразумеваним подешавањима и широко се користи на Андроид телефонима са dm-verity инсталационим софтвером.
Датотеке које морају бити писиве
Са root ro, неки програми очекују да пишу у /etc или током иницијализацијеМожете га преместити у /var/etc и додати симболичку везу за све што треба да се промени (нпр., везе NetworkManager-а у /etc/NetworkManager/system-connections). Имајте на уму да systemd-journald захтева да /etc/machine-id постоји у коренском директоријуму (не симболичка веза) како би се избегло прекидање раног покретања.
Да бисте сазнали које се промене у извршењу, користите dracut-overlayroot: преклапа tmpfs преко корена, и све што је написано се појављује у /run/overlayroot/u. Додајте модул у /usr/lib/dracut/modules.d/, укључите overlayroot у dracut и подесите overlayroot=1 у линији језгра; на овај начин ћете видети шта да мигрирате у /var.
Корисни примери: pacman и NetworkManager
У Арчу је згодно Преместите Pacman базу података у /usr/lib/pacman тако да rootfs увек одражава инсталиране пакете. Затим, преусмерите кеш на /var/lib/pacman и линкујте. Да бисте променили листу одраза без додиривања корена, преместите је у /var/etc и ипак је линкујте.
Са NetworkManager-ом, преместите системске везе у /var/etc/NetworkManager и линк из /etc/NetworkManager/system-connections. Ово одржава корен непроменљивим и конфигурацију активном тамо где би требало да буде доступна за писање.
Конструкција верности и тестирање
Из уживог прегледа и са свим савршеним и монтираним у ro, креирајте дрво и roothash са VeritySetuP formatКада се покрене, исписује линију Root Hash-а, коју можете сачувати у roothash.txt. Покрените је за тестирање са veritysetup , open root-device root verity-device $(cat roothash.txt) и mount `/dev/mapper/root`.
Ако вам је драже, прво генерише дрво у датотеку (verity.bin) и затим га запишите на VERITY партицију. Резултујући скуп је: коренска слика, verity стабло и коренски хеш који ћете закачити при покретању система.
Конфигуришите линију језгра
Додајте ове параметре: systemd.verity=1, roothash=contents_of_roothash.txt, systemd.verity_root_data=ROOT-PATH (нпр. LABEL=OS) и systemd.verity_root_hash=VERITY-PATH (нпр. LABEL=VERITY). Подесите systemd.verity_root_options на restart-on-corruption или panic-on-corruption за строге политике.
Друге препоручене опције: ro (ако не користите EROFS/squashfs), rd.emergency=поновно покретање y rd.shell=0 (спречити неовлашћене шкољке ако покретање система не успе) и закључавање=поверљивост да заштити меморију језгра од приступа.
Додатне партиције са Verity
Не само корен: Можете дефинисати друга мапирања у /etc/veritytab и systemd-veritysetup@.service ће их саставити при покретању система. Запамтите: лакше је RW монтирати партицију која није root, а root корисник може да онемогући Verity на тим партицијама, тако да је безбедносна вредност тамо нижа.
Безбедност: Безбедно покретање, UKI и потписани модули
dm-verity није чаробни метак. Потпишите UKI и омогућите Secure Boot са својим кључевима да би се спречило да било ко замени kernel/initramfs/cmdline (што укључује root хеш). Алати попут sbupdate-git или sbctl помажу у очувању потписаних слика и нетакнутог ланца покретања.
Ако омогућите закључавање језгра или верификацију потписа модула, DKMS или модули ван стабла морају бити потписани или се неће учитати. Размотрите прилагођено језгро са подршком за потписивање за ваш цевовод (погледајте потписане модуле језгра).
Шифровање, TPM и мерење
dm-verity штити интегритет, неповерљивостМожете оставити root директоријум нешифрованим ако не садржи тајне и ако је ланац покретања заштићен. Ако користите кључне датотеке из root директоријума да бисте откључали друге томове, онда је добра идеја да га шифрујете.
Са TPM 2.0, systemd-cryptenroll омогућава повезивање кључева са PCR-овима 0,1,5,7 (фирмвер, опције, GPT, статус безбедног покретања). Додајте rd.luks.options=LUKS_UUID=tpm2-device=auto и обавезно укључите TPM2 подршку у initramfs. systemd-boot мери kernel.efi у PCR4, што је корисно за поништавање кључева ако се UKI или његова командна линија промене.
Ажурирања и модели имплементације
Верификовани корен само за читање Не ажурира се помоћу менаџера пакета на традиционалан начинИдеално је креирати нове слике помоћу алата као што су Пројекат Јокто и објавите их. systemd има systemd-sysupdate и systemd-repart за робусно преузимање и флешовање образа.
Друга стратегија је А/Б шемаЗадржавате два корена и два идентитета. Копирајте активни корен у неактивни корен, примените измене и поновите идентитет. Вратите се на претходно стање при следећем покретању. Ако користите UKI, не заборавите да ажурирате хеш корена у cmd линији или поново изградите потписани UKI.
За опциону истрајност, користите OverlayFS на верификованом корену са горњим `upper` у tmpfs-у или диску. Такође можете проследити systemd.volatile=overlay за привремену перзистентност. Flatpak олакшава инсталирање апликација у /var и /home без додиривања /.
Постоје аутоматизовани пакети (нпр. verity-squash-root у AUR-у) који граде корен squashfs-а и потпишите roothash помоћу kernela и initramfs-а, што вам омогућава да бирате између трајног или ефемерног режима и чувате најновије rootfs датотеке као резервну копију. Напомена: додавање трајности верификованом root-у има уске случајеве употребе; покушајте да сачувате податке апликације на одвојеним партицијама.
Андроид: систем као корен, AVB и преклапања произвођача
Од Андроида 10, RootFS престаје да ради на RAM диску и интегрише се са system.img. (system-as-root). Уређаји који се покрећу са Android 10 увек користе ову шему и захтевају ramdisk за dm-linear. BOARD_BUILD_SYSTEM_ROOT_IMAGE је подешено на false у овој верзији да би се направила разлика између коришћења ramdiska и директног активирања system.img.
Андроид 10 укључује динамичке партиције и иницијализација прве фазе што активира логичку системску партицију; језгро је више не монтира директно. Системски OTA захтевају дизајн „систем као корен“, што је обавезно на Андроид 10 уређајима.
Ни у једном А/Б систему, држите опоравак одвојено од покретања системаЗа разлику од A/B, не постоји резервна копија boot_a/boot_b, тако да уклањање опоравка у не-A/B режиму може вас оставити без режима опоравка ако ажурирање покретања не успе.
Језгро монтира system.img у /converity преко две путање: вбут 1.0 (закрпе за језгро да би се анализирали Андроид метаподаци у /system и извели dm-verity параметри; командна линија укључује root=/dev/dm-0, skip_initramfs и init=/init са dm=…) или vboot 2.0/AVB, где покретачки програм интегрише libavb, чита дескриптор хеш стабла (у vbmeta или system), конструише параметре и прослеђује их језгру у командној линији, са FEC подршком и заставицама попут restart_on_corruption.
Са системом као кореном, Не користите BOARD_ROOT_EXTRA_FOLDERS за коренске фасцикле специфичне за уређај: оне ће нестати приликом флешовања GSI-ја. Дефинишите специфичне фасцикле под /mnt/vendor/ , које fs_mgr аутоматски креира, и референцирају их у fstab-у стабла уређаја.
Андроид омогућава преклапање добављача из /product/vendor_overlay/Команда init ће монтирати у /vendor поддиректоријуме који испуњавају захтеве SELinux контекста и постојање /vendor/ Захтева CONFIG_OVERLAY_FS=yy, на старијим језгрима, закрпу override_creds=off.
Типична имплементација: инсталира претходно компајлиране датотеке у уређај/ / /vendor_overlay/, додајте их у PRODUCT_COPY_FILES помоћу find-copy-subdir-files у $(TARGET_COPY_OUT_PRODUCT)/vendor_overlay, дефинишите контексте у file_contexts за etc и app (нпр. vendor_configs_file и vendor_app_file) и дозволите монтирање на тим контекстима у init.te. Тестирајте са atest vfs_mgr_vendor_overlay_test у userdebug.
Решавање проблема: порука о оштећењу dm-verity на Андроиду
На уређајима са А/Б слотовима, промените слотове или Флешовање vbmeta/boot-а без конзистентности са roothash-ом Ово може покренути упозорење: dm-verity оштећење, ваш уређај није поуздан. Команде попут fastboot flash –disable-verity –disable-verification vbmeta vbmeta.img онемогућавају верификацију, али остављају систем без икаквих гаранција интегритета.
Неки бутлоудери подржавају fastboot oem disable_dm_verity и његова супротност, enable_dm_verity. Ради на неким моделима, али не на другима; и може захтевати kernel/magisk са подешеним заставицама. Користите на сопствени ризик: разуман поступак је поравнајте boot, vbmeta и system, потпишите или регенеришите стабло и уверите се да очекивани хеш корена одговара конфигурисаном.
Ако након упозорења можете да наставите да притискате дугме за напајање, систем се покреће, али више немате нетакнут ланац поверењаДа бисте уклонили поруку без жртвовања безбедности, вратите оригиналне потписане слике или поново изградите/верификујте vbmeta са исправним хеш стаблом, уместо да онемогућите verity.
i.MX и OpenWrt платформе
На i.MX6 (нпр. sabresd), конфигуришите језгро са DM_VERITY и FEC подршком, генеришите стабло помоћу veritysetup, безбедно сачувајте хеш корена и проследите одговарајуће параметре у cmd линији или интегришите путем initramfs-а помоћу systemd-veritysetup. Ако не користите dm-crypt, не треба вам CAAM за verity; фокус је на интегритету.
У OpenWrt-у и у уграђени Линукс системи са OpenEmbedded-ом, Постоје напори да се интегришу dm-verity и SELinux (Bootlin послови су ревидирани са намером укључивања подршке). То је природно уклапање: рутери и мрежна опрема имају користи од непроменљивог, верификованог и MAC-отпорног корена.
Ручно конструисање стабла и метаподатака (детаљан приказ)
cryptsetup може генерисати стабло за вас, али ако више волите да разумете формат, дефиниција компактне линије табеле укључује: име мапирања, уређај за пренос података, величине блокова података и хеша, величина слике у блоковима, позиција hash_start (слика блока + 8 ако је спојено), хеш корена и со. Након генерисања спојених слојева (од врха до дна, искључујући слој 0), записујете стабло на диск.
Да све спакујем, саставите dm-verity табелу, потпишите је (типично RSA-2048) и групишите потпис+табелу у метаподацима са верзионисаним заглављем и магичним бројем. Затим, спаја слику система, verity метаподатке и хеш стабло. У fstab-у, означава fs_mgr као verify и смешта јавни кључ у /boot/verity_key да би потврдио потпис.
Оптимизуј са SHA-2 убрзања за ваш процесор и подесите читање унапред/префетч_кластер. На ARM хардверу, NEON SHA-2 (ARMv7) и SHA-2 екстензије (ARMv8) значајно смањују трошкове верификације.
Приликом било каквог распоређивања, запамтите да Вредност коренског хеша мора бити заштићена: било да је компајлирано у потписани UKI, у потписану партицију за покретање система или валидирано од стране покретачког програма користећи AVB. Све након те тачке наслеђује то поверење.
Са свим горе наведеним наведеним, dm-verity постаје чврст темељ за непроменљиве, мобилне и уграђене системе, подржавајући трансакциона ажурирања, преклапања конфигурације и модеран безбедносни модел који смањује површину напада и спречава упорност без жртвовања перформанси.
