Ja esat sekojis Android notikumiem, pēdējo pāris gadu laikā ir bijis dzirdējis vārdu “Verified Boot”. Google iepazīstināja ar drošības funkciju Android 4.4 (Kitkat), pilnībā neuzbāzīgā veidā, un lēnām palielina redzamību jaunākajās Android operētājsistēmas versijās.
Pēdējo pāris dienu laikā mēs esam redzējuši jaunumus par „ stingri piespiedu verificētas sāknēšanas ” esamību Google jaunākajā lietotajā mobilajā operētājsistēmā. Android Nougat izmantos augstāku drošības pārbaudes līmeni, kad ierīce sāk darboties. Kaut gan, izmantojot Marshmallow, Verified Boot tikai sniedza lietotājam brīdinājumu, ja tā atklāja kaut ko nepareizu ar sistēmas nodalījumu, Android Nougat to darīs vienu soli tālāk un izmantos to, ko Google sauc par „stingri piespiedu verificētu palaišanu”, kas neļaujiet ierīcei palaist vispār, ja tā atklāj novirzes nodalījumā, izmaiņas, kas veiktas bootloader, vai ierīcē ir "ļaunprātīga" koda klātbūtne. Tas liek domāt: „Ko tieši tas nozīmē lietotājiem?”, Izrādās, atbilde atšķiras divās galvenajās Android lietotāju kategorijās (gadījuma un enerģijas lietotāji), un mēs sniegsim atbildi abiem no tiem. .
Stingri piespiedu verificēta sāknēšana
Pirmkārt, nedaudz fona par verificēto sāknēšanu: Parasti, kad Android vada starpsienu verifikācijas testu, tas tiek darīts, dalot nodalījumus 4KiB blokos un pārbaudot tos pret parakstītu tabulu. Ja viss pārbauda, tas nozīmē, ka sistēma ir pilnīgi tīra. Tomēr, ja daži bloki tiek izmainīti vai bojāti, Android informē lietotāju par problēmām un atstāj to lietotājam (vai ne).
Viss, kas gatavojas mainīt ar Android Nugātu, un Stingri piespiedu verificēta sāknēšana. Kad verificētā sāknēšana darbojas piespiedu režīmā, tā neuzņems nekādus defektus starpsienās. Ja tas atklāj kādas problēmas, tas neļaus ierīcei palaist, un tas var ļaut lietotājam ielādēt drošā režīma vidē, lai mēģinātu labot problēmas. Tomēr stingri piespiedu verificēta sāknēšana nav tikai pārbaude pret sliktiem datu blokiem. Tā parasti var labot kļūdas datu blokos. Tas ir iespējams, pateicoties Forward Error korekcijas kodiem, kurus var izmantot, lai labotu kļūdas datu blokos. Tomēr tas ne vienmēr var darboties, un gadījumos, kad tā nav, jūs esat diezgan miris ūdenī.
Stingri piespiedu apstiprināts sākums: labs, sliktais un neglīts
1. Labi
Verificētās sāknēšanas ieviešana Android ierīcēs uzlabos ierīču drošību . Ja ierīce tiek inficēta ar ļaunprātīgu programmatūru, Strictly Enforced Verified Boot to atklās nākamajā reizē, kad sākat ierīci, un vai nu salabojiet to, vai arī, iespējams, pamudināt jūs darīt kaut ko par to.
Šī funkcija arī pārbaudīs datu korupciju, un vairumā gadījumu, pateicoties FEC kodiem, tā varēs labot datus, kas ievadīti datos. Google izmanto FEC kodus, kas var labot vienu nezināmu bitu kļūdu 255 bitos . Protams, tas šķiet diezgan mazs skaitlis, bet pieņemsim, ka tas ir perspektīvā attiecībā uz mobilo ierīci:
Piezīme: zemāk norādītās vērtības tiek ņemtas no Google Engineer Sami Tolvanen emuāra ziņojumā Android izstrādātājiem.
Google varēja izmantot RS (255, 223) FEC kodus: šie kodi varēja labot 16 nezināmas bitu kļūdas 255 bitos, bet telpu virs galvas, jo 32 biti liekie dati, būtu bijis gandrīz 15%, un tas ir daudz, jo īpaši mobilajās ierīcēs. Pievienojiet šo faktu, ka Android ir dominējošā operētājsistēma budžeta viedtālruņos, kuros ir 4–8 GB atmiņas, un 15% papildu vietas, šķiet, šķiet daudz.
Zaudējot kļūdu labošanas spējas, Google atbalsta telpu ietaupījumu, nolēma izmantot RS (255, 253) FEC kodus. Šie kodi var labot tikai vienu nezināmu kļūdu 255 bitos, bet telpu pieskaitāmās izmaksas ir tikai 0, 8%.
Piezīme: RS (255, N) ir Reed-Solomon kodu attēlojums, kas ir kļūdu labošanas kodu veids.
2. Slikti
Kādreiz esat dzirdējuši par “Monētas pusēm ir divas puses”? Protams, jums ir. Lai gan Google nodomi ar stingri piespiedu pārbaudi bija neapšaubāmi tīri kā vienradzis, viņi nāk ar savām problēmām.
Ja stingri izpildītas verificētas sāknēšanas pārbaudes pārbauda ļaunprātīgu programmatūru, tā arī pārbauda, vai kodols, bootloader un citi sīkumi ir nelikumīgi, bet tas nozīmē, ka Android nugāts, iespējams, saskarsies ar daudzām problēmām, kas saistītas ar iesakņošanu, un mirgo Custom ROM, jo Verified Boot nevar atšķirt nevēlamu ļaunprātīgas programmatūras kodu un kodu, kas atbloķēja jūsu bootloader. Tas nozīmē, ka, ja ierīcei ir pievienota bloķēta bootloader, un jūsu OEM neļauj ielādēt ielādes sistēmu, jūs to nevarat izdarīt. Cerams, ka kāds to izdomās.
Par laimi, lielākā daļa cilvēku, kas sakņojas savās ierīcēs, un zibatmiņas Custom ROM, lai pievienotu funkcijas un funkcionalitāti, iet ar attīstītājiem draudzīgiem tālruņiem, piemēram, Nexus. Attiecībā uz šo tēmu ir daudz jāapsver, un tas noteikti nav Custom ROM beigas, vismaz ne ierīcēs, kas ir aprīkotas ar atbloķētu bootloader, vai kas ļauj atbloķēt bootloader. Tomēr ierīces, piemēram, Samsung tālruņi, oficiāli neļauj ielādēt ielādes slodzi, un šajās ierīcēs, atverot bootloader, noteikti tiks uzskatīts, ka Verified Boot ir problēma, kas neļauj ierīcei sākt.
Vēl viena problēma, kas radīsies stingri piespiedu verifikācijas sāknēšanas laikā, ir tāda, kas ietekmēs pat lietotājus, kuri nav īsti ieinteresēti, lai iegūtu root privilēģijas, vai instalētu pielāgotus ROM. Laika gaitā, lietojot ierīci, atmiņā ir dabiski datu bojājumi; nevis ļaunprātīgas programmatūras klātbūtnes dēļ, bet vienkārši tāpēc, ka tas notiek. Parasti tā nav problēma, vai vismaz ne tik nopietna problēma, kā Verificētā sāknēšana to pārvērš. Ja jums ir bojāti dati, ka Strictly Enforced Verified Boot nevar ielādēt boot, tas neļaus ierīcei palaist. Manuprāt, tas ir lielāks, redzamāks jautājums, nekā daži korumpēti dati par lietotāja nodalījumu.
3. Ugly
Visās priekšrocībās, kas saistītas ar Verificētās sāknēšanas ieviešanu, un visām iespējamām problēmām, visbiežāk satraucošs, iespējams, ir fakts, ka OEM var sākt to nepareizi izmantot, lai bloķētu savas ierīces, lai cilvēki nevarētu izmantot Android, lai to izmantotu būt: atvērts, attīstītājs draudzīgs un pilnībā pielāgojams. Stingri piespiedu verificēta sāknēšana nodos oriģinālo iekārtu ražotāju rokās, kas ir pilnvaras nodrošināt, lai cilvēki nevarētu atbloķēt bootloaders savās ierīcēs, tādējādi aizliedzot tiem instalēt pielāgotus ROM un iezīmes uzlabojošus rīkus, piemēram, Xposed moduļus.
Android Nougat: radikālas izmaiņas Android darbībā?
Lai gan mēs esam pārliecināti, ka Google nodomi bija vienkārši, lai izvairītos no iespējamām problēmām gadījuma Android lietotājiem, kuri nezina, ko darīt, ja viņu ierīce ir ietekmējusi ļaunprātīgu programmatūru, vai ja to atmiņa bija bojāta datu blokos, tā var būt nodevusi OEM un ražotājs ir lielisks līdzeklis, lai bloķētu lietotājus ar to, ko viņi piedāvā, un neko citu.
Protams, kāds izdomās šo situāciju vai risinās šo situāciju, un mēs ceram, ka viņi to darīs Android patiesajā garā. Līdz brīdim, kad kāds izdomās risinājumu, tomēr viss, ko mēs, lietotāji varam darīt, ir nodrošināt, ka mēs iegādājāmies mūsu ierīces no attīstītājiem draudzīgiem ražotājiem.
Featured Image Pieklājība: Flickr
