Ако сте следвали развитието на Android, сигурно сте чули името "Verified Boot" доста през последните няколко години. Google въведе функцията за сигурност в Android 4.4 (Kitkat) по напълно ненатрапчив начин и бавно увеличава видимостта си в по-новите версии на своята операционна система Android.
През последните няколко дни видяхме новини за наличието на „ Строго принудително потвърдено стартиране “ в последната версия на Google за най-използваната мобилна операционна система в света. Android Nougat ще използва по-високо ниво на проверка за сигурност, когато устройството ви се зареди. Докато, на Marshmallow, Verified Boot само предупреждава потребителя, в случай, че открие нещо нередно със системния дял, Android Nougat ще го направи още една стъпка напред и ще използва това, което Google нарича „Strictly Enforced Verified Boot“, което ще не позволявайте на устройството да се зарежда изобщо, в случай, че открие аномалии в дяла, промените, направени в bootloader, или наличието на "злонамерен" код в устройството. Това повдига въпроса: "Какво точно означава това за потребителите?", Се оказва, че отговорът се различава за двете основни категории потребители на Android (случайни и силни потребители) и ние ще дадем отговор и за двамата.,
Строго принудително потвърдено зареждане
Първо, малко фон на Verified Boot: Обикновено, когато Android изпълнява тест за проверка на дялове, той прави това, като разделя дяловете на 4KiB блока и ги проверява срещу подписана таблица. Ако всичко се провери, това означава, че системата е напълно чиста. Въпреки това, ако някои блокове излязат да бъдат подправени или повредени, Android информира потребителя за проблемите и оставя на потребителя да го разреши (или не).
Всичко, което предстои да се промени с Android Nougat и Strictly Enforced Verified Boot. Когато Verified Boot се стартира в Enforced режим, няма да понесе никакви грешки в дяловете. Ако той открие някакви проблеми, той няма да позволи на устройството да стартира системата и може да позволи на потребителя да зареди в безопасна среда, за да опита и да коригира проблемите. Обаче Strictly Enforced Verified Boot не е само проверка срещу лоши блокове данни. Обикновено може да коригира грешки и в блоковете с данни. Това става възможно поради наличието на кодове за коригиране на грешки, които могат да се използват за коригиране на грешки в блоковете с данни. Все пак, това не винаги може да работи, а в случаите, когато това не стане, вие сте почти мъртви във водата.
Строго принудително Проверено Boot: The Good, The Bad и The Ugly
1. Доброто
Активирането на провереното зареждане на устройства с Android ще подобри сигурността на устройствата. В случай, че устройството се зарази от зловреден софтуер, Strictly Enforced Verified Boot ще го открие при следващото зареждане на устройството и ще го поправите или вероятно ще ви подкани да направите нещо по въпроса.
Тази функция също така ще проверява за повреда на данните и в повечето случаи ще може да коригира всякакви грешки, въведени в данните, благодарение на кодовете FEC. Google използва FEC кодове, които могат да коригират една неизвестна битова грешка в 255 бита . Разбира се, това е доста малък брой, но нека да го поставим в перспектива, по отношение на мобилно устройство:
Забележка: Стойностите по-долу са взети от публикацията в блога на инженера на Google Сами Толван в разработчиците на Android.
Google би могъл да използва RS (255, 223) FEC кода: тези кодове биха могли да коригират 16 неизвестни битови грешки в 255 бита, но пространствените режийни поради 32-те бита на излишни данни биха били почти 15%, и това е много, особено на мобилни устройства. Добавете това към факта, че Android е преобладаващата операционна система на бюджетни смартфони, които се доставят с 4–8 GB памет и 15% допълнително пространство изглежда много.
Като пожертва възможностите за коригиране на грешки, в полза на спестяване на пространство, Google реши да използва RS (255, 253) FEC кода. Тези кодове могат да коригират само една неизвестна грешка в 255 бита, но пространствените разходи са само 0.8%.
Забележка: RS (255, N) е представяне на кодовете на Reed-Solomon, които са вид кодове за коригиране на грешки.
2. Лошото
Някога чували ли сте за „Има две страни на една монета“? Разбира се, че имате. Въпреки че намеренията на Google с Strictly Enforced Verified Boot несъмнено са чисти като еднорог, те идват със собствен набор от проблеми.
Когато Strictly Enforced Verified Boot проверява за злонамерен софтуер, той също проверява за незаконни модификации на ядрото, bootloader и други неща, с които няма да ви отегчавам, но това означава, че Android Nougat вероятно ще срещне много проблеми с вкореняване, и мига Персонализираните ROM, тъй като Verified Boot не може да разграничи нежелания код от злонамерен софтуер и кода, който отключва буутлоудъра. Което означава, че ако вашето устройство е с заключен буутлоудър и вашият OEM не позволява отключване на буутлоудъра, почти не можете да го направите. Надяваме се, че някой ще разбере за това.
За щастие, повечето хора, които корени техните устройства, и флаш потребителски ROM за допълнителни функции и функционалност, отивам с разработчици приятелски телефони, като Nexus. Има много да се обмисли по отношение на тази тема и определено не е краят на Custom ROM, поне не на устройства, които идват с отключен буутлоудър, или които позволяват отключване на bootloader. Въпреки това, устройства като телефони на Samsung не позволяват официално отключване на буутлоудъра, а на тези устройства отключването на буутлоудъра определено ще се разглежда като "проблем" от Verified Boot, което предотвратява зареждането на устройството.
Друг проблем, който ще възникне при Strictly Enforced Verified Boot, е този, който ще засегне дори потребителите, които наистина не се интересуват от получаването на root права, или инсталирането на Custom ROM. С течение на времето, докато използвате устройството си, е задължително в паметта да има естествени корупционни данни; не поради наличието на зловреден софтуер, а просто защото се случва. Това обикновено не е проблем, или поне не толкова сериозен проблем, в който Провереното зареждане ще го превърне в. Ако имате повредени данни, които Strictly Enforced Verified Boot не може да коригира при зареждане, няма да позволи на устройството да се зарежда. По мое мнение това е по-голям, по-видим проблем, отколкото някои корумпирани данни в потребителския дял.
3. Грозната
Във всички предимства от прилагането на Verified Boot и всички потенциални проблеми, най-тревожното, вероятно е фактът, че производителите на оригинално оборудване биха могли да започнат да злоупотребяват с това, за да заключват устройствата си, така че хората да не могат да използват Android за това, за което е предназначено да бъдат: отворени, удобни за разработчици и напълно приспособими. Strictly Enforced Verified Boot ще бъде поставен в ръцете на производителите на оригинално оборудване, които могат да гарантират, че хората не могат да отключват буутлоудърите на устройствата си, като по този начин ги забраняват да инсталират персонализирани дискове и инструменти за подобрение на функциите, като модулите Xposed.
Android Nougat: радикална промяна в начина, по който Android работи?
Въпреки че сме сигурни, че намеренията на Google са просто да се избегнат потенциални проблеми за обикновените потребители на Android, които не биха знаели какво да правят в случай, че устройството им е било засегнато от злонамерен софтуер, или ако паметта им има повредени блокове данни, може да е предоставила на OEM производители и производителят е идеалният инструмент за заключване на потребителите да живеят с това, което им се предлага, и нищо повече.
Разбира се, някой ще измисли подвиг или решение за тази ситуация и се надяваме, че ще го направят в истинския дух на Android. Докато някой не намери решение, всичко, което ние, както потребителите могат да направят, е да гарантираме, че купуваме нашите устройства от производителите, които са подходящи за разработчици.
Препоръчани Снимки: Flickr
![Текстови съобщения и шофиране: шофиране докато сте вкоренени [инфографика]](https://gadget-info.com/img/tech/525/texting-driving-driving-while-intexticated-2.jpg)
