Secure boot control что это
Вместе с анонсом Windows 11, компания Microsoft опубликовала и новые системные требования для установки операционной системы Windows 11. В них требуется поддержка TPM 2.0, UEFI и Secure Boot. В результате, вокруг этих технологий возникло много вопросов. Пользователей интересует, что такое Secure Boot, как проверить его наличие на компьютере и как его включить в BIOS (UEFI), если он отключен.
Что такое Secure Boot или безопасная загрузка
Secure Boot – это протокол проверки загружаемых операционных систем, который является частью UEFI. Данный протокол проверяет цифровую подпись операционных систем или драйверов UEFI, которые загружаются при включении компьютера, и при отсутствии такой подписи предотвращает их запуск.
Использование Secure Boot защищает систему от внедрения вредоносного кода в загружаемые компоненты операционных систем. Такое внедрение, например, использовалось вирусом-вымогателем Petya, который распространялся в 2017 году. Также Secure Boot может использоваться для ограничения списка ОС, которые могут запускаться на компьютере.
На данный момент Secure Boot поддерживается такими операционными системами как Windows 8 и Windows 10, а также некоторыми дистрибутивами Linux, например, Fedora, openSUSE, RHEL, CentOS, Debian и Ubuntu.
В еще не выпущенной Windows 11 протокол Secure Boot является обязательным условием и указан в системных требованиях. Хотя, с помощью небольших ухищрений текущие сборки Windows 11 можно установить без TPM и Secure Boot.
Немного про UEFI и Secure Boot
UEFI (Unified Extensible Firmware Interface) — замена устаревшему BIOS. Эта спецификация была придумана Intel для Itanium, тогда она еще называлась EFI (Extensible Firmware Interface), а потом была портирована на x86, x64 и ARM. Она разительно отличается от BIOS как самой процедурой загрузки, так и способами взаимодействия с ОС. Если вы купили компьютер в 2010 году и позже, то, вероятнее всего, у вас UEFI.
Основные отличия UEFI от BIOS:
Как происходит загрузка в UEFI?
С GPT-раздела с идентификатором EF00 и файловой системой FAT32, по умолчанию грузится и запускается файл \efi\boot\boot[название архитектуры].efi, например \efi\boot\bootx64.efi
Т.е. чтобы, например, создать загрузочную флешку с Windows, достаточно просто разметить флешку в GPT, создать на ней FAT32-раздел и просто-напросто скопировать все файлы с ISO-образа. Boot-секторов больше нет, забудьте про них.
Загрузка в UEFI происходит гораздо быстрее, например, загрузка моего лаптопа с ArchLinux с нажатия кнопки питания до полностью работоспособного состояния составляет всего 30 секунд. Насколько я знаю, у Windows 8 тоже очень хорошие оптимизации скорости загрузки в UEFI-режиме.
Secure Boot
«Я слышал, что Microsoft реализовывает Secure Boot в Windows 8. Эта технология не позволяет неавторизированному коду выполняться, например, бутлоадерам, чтобы защитить пользователя от malware. И есть кампания от Free Software Foundation против Secure Boot, и многие люди были против него. Если я куплю компьютер с Windows 8, смогу ли я установить Linux или другую ОС? Или эта технология позволяет запускать только Windows?»
Начнем с того, что эту технологию придумали не в Microsoft, а она входит в спецификацию UEFI 2.2. Включенный Secure Boot не означает, что вы не сможете запустить ОС, отличную от Windows. На самом деле, сертифицированные для запуска Windows 8 компьютеры и лаптопы обязаны иметь возможность отключения Secure Boot и возможность управления ключами, так что беспокоится тут не о чем. Неотключаемый Secure Boot есть только на планшетах на ARM с предустановленной Windows!
Что дает Secure Boot? Он защищает от выполнения неподписанного кода не только на этапе загрузки, но и на этапе выполнения ОС, например, как в Windows, так и в Linux проверяются подписи драйверов/модулей ядра, таким образом, вредоносный код в режиме ядра выполнить будет нельзя. Но это справедливо только, если нет физического доступа к компьютеру, т.к., в большинстве случаев, при физическом доступе ключи можно заменить на свои.
В Secure Boot есть 2 режима: Setup и User. Первый режим служит для настройки, из него вы можете заменить PK (Platform Key, по умолчанию стоит от OEM), KEK (Key Exchange Keys), db (база разрешенных ключей) и dbx (база отозванных ключей). KEK может и не быть, и все может быть подписано PK, но так никто не делает, вроде как. PK — это главный ключ, которым подписан KEK, в свою очередь ключами из KEK (их может быть несколько) подписываются db и dbx. Чтобы можно было запустить какой-то подписанный .efi-файл из-под User-режима, он должен быть подписан ключом, который в db, и не в dbx.
Для Linux есть 2 пре-загрузчика, которые поддерживают Secure Boot: Shim и PRELoader. Они похожи, но есть небольшие нюансы.
В Shim есть 3 типа ключей: Secure Boot keys (те, которые в UEFI), Shim keys (которые можно сгенерировать самому и указать при компиляции), и MOKи (Machine Owner Key, хранятся в NVRAM). Shim не использует механизм загрузки через UEFI, поэтому загрузчик, который не поддерживает Shim и ничего не знает про MOK, не сможет выполнить код (таким образом, загрузчик gummiboot не будет работать). PRELoader, напротив, встраивает свои механизмы аутентификации в UEFI, и никаких проблем нет.
Shim зависит от MOK, т.е. бинарники должны быть изменены (подписаны) перед тем, как их выполнять. PRELoader же «запоминает» правильные бинарники, вы ему сообщаете, доверяете вы им, или нет.
Оба пре-загрузчика есть в скомпилированном виде с валидной подписью от Microsoft, поэтому менять UEFI-ключи не обязательно.
Secure Boot призван защитить от буткитов, от атак типа Evil Maid, и, по моему мнению, делает это эффективно.
Спасибо за внимание!
Конвертация диска с MBR в GPT
Конвертацию диска из MBR в GPT можно выполнить непосредственно в процессе установки Windows 11, вызвав командную строку с помощью комбинации клавиш Shift-F10 (или Shift-Fn-F10 ), либо заранее, из рабочей Windows 10. Конвертацию при установке мы рассматривали в статье о преобразовании диска с MBR в GPT, здесь же будет рассмотрена конвертация из рабочей Windows 10.
Итак, для начала нужно открыть меню « Параметры » (комбинация клавиш Win-i ), перейти в раздел « Обновление и безопасность – Восстановление » и нажать на кнопку « Перезагрузить сейчас ».
После этого появится меню с дополнительными действиями. Здесь нужно выбрать « Поиск и устранение неисправностей », а потом « Командная строка ». Также может понадобиться выбор пользователя и ввод пароля.
В результате перед вами появится командная строка. Сначала нужно выполнить команду, которая проверит возможность конвертации диска:
Чтобы узнать номер диска выполните следующие команды:
В результате в консоль будет выведен список дисков и их объем. Используя эту информацию, можно определить номер диска, который необходимо конвертировать.
После успешной проверки можно запускать конвертацию диска. Для этого нужно выполнить следующую команду:
Где 0 – это номер диска.
После конвертации диска с MBR в GPT нужно зайти в BIOS и выполнить следующие настройки:
- Отключить эмуляцию старого BIOS;
- Включить безопасную загрузку.
Подробней в статьях:
Как включить Secure Boot в BIOS
Для работы Secure Boot диск должен быть в формате GPT. Посмотрите раздел о конвертации диска (выше).
Процесс включения Secure Boot отличается в зависимости от производителя. Точные инструкции по работе с вашим BIOS можно получить в инструкции к материнской плате или ноутбуку. Здесь мы покажем настройку BIOS на примере материнской платы от ASUS.
Чтобы включить Secure Boot на материнской плате ASUS нужно войти в настройки BIOS, активировать режим « Advanced mode ( F7) » и перейти в раздел « Boot ». Здесь нужно открыть подраздел « CSM (Launch Compatibility Support Module) », который отвечает за эмуляцию старого BIOS.
Если функция « CSM » включена, то ее нужно отключить.
После этого нужно вернуться в раздел « Boot » и перейти в подраздел « Меню безопасной загрузки ».
Здесь нужно поменять параметр « Тип ОС » на « Режим Windows UEFI ».
После этого сохраняем настройки BIOS и загружаемся в Windows 10. Если диск был сконвертирован в GPT, то загрузка должна пройти без проблем.
Настройка Secure Boot на других платах :
- Номер диска неправильный. Используйте diskpart чтобы определить номер диска с Windows. В статье показан пример как это делается.
- Конвертация данного диска в GPT невозможна. У программы mbr2gpt есть ограничения. Например, на диске не должно быть больше 3 разделов и не должно быть расширенного/логического раздела.
Все очень здорово и подробно, большое спасибо за подробную инструкцию. Очень долго искал такой доходчивый вариант порядка действий. Большое спасибо
Спасибо большое, мне помогло.
Подскажите, выключил в BIOS CSM, затем поставил режим Windows UEFI и после это F10 и ПК перезагружается в BIOS и не идет дальше
Скорее всего, у вас диск в формате MBR, раз был включен CSM.
Верните все обратно, чтобы загрузилась Windows, и выполните конвертацию MBR в GPT как описано в статье. После конвертации диска в GPT можно отключать CSM и включать безопасную загрузку.
Подскажите перед тем как отключить CSM в биосе я выполнил конвертацию в GPT на диске . Далее я переключил винду на UEFI но проблема осталась винда не запускается горит только знак Asus и даже в биос не даёт зайти лечится только вытаскиванием батарейки !
Не знаю в чем проблема. Возможно ваша Windows не проходит проверку Secure Boot или конвертация не прошла.
Александр,
В меню безопасной загрузки указано Пользователь, а не Включено
Что делать ?
Возможно у вас включен CSM и поэтому настройки Secure Boot просто не доступны.
Пытаюсь сделать конвертацию MBR в GPT разными способами, но всегда fail. Выяснилось, что Windows при установке создала дополнительный раздел 500 мегабайт на SSD, на котором я её устанавливал в своё время, на котором находятся boot файлы, и скорее всего из-за этого раздела конвертация становится невозможна. Как быть? Сносить Windows, удалять дополнительный раздел, конвертировать и снова устанавливать Windows, Может можно что-нибудь сделать, чтобы сохранить систему?
А с какого накопителя выполняется загрузка системы? Посмотрите загрузочный диск в BIOS в разделе BOOT.
Если загрузка выполняется с этого второго SSD, то я вижу 2 варианта:
Я, наверное, неправильно выразился. SSD один и тот же, но разбит Виндой при её установке на два раздела. На одном установлена сама Винда 10, на втором (500 мегабайт) только загрузочные файлы. Физический SSD один. При попытке преобразования MBR в GPT утилитой из командной строки просто выдаётся постоянный fail без объяснения причин, а утилитой из загрузочного DVD с утилитами и Live Windows пишет, что внимание, загрузочные файлы находятся на другом диске и что при конвертации Винда перестанет загружаться. Можно ли из-под той же Windows PE с DVD перенести простым копированием всё содержимое второго раздела на раздел с Windows и произвести конвертацию? Загрузится ли Windows после такого переноса файлов загрузки и ликвидации второго раздела?
Сорри, посидел вечерок и всё сделал. Перенес бут на диск с системой, сделал его активным, удалил раздел с бывшим бутом, убедился, что система загружается, потом утилитой mbr2gpt конвертировал системный диск. Включил secure boot, всё работает. Спасибо за статью с ликбезом!
Поэтому, чтобы установить другую операционку, данную опцию следует отключить, либо выставить значение Custom вместо Standart.
Настройка находится в одном из разделе:
- Security (переводится как безопасность).
- System Configuration (системная конфигурация).
- Boot (переводится как загрузиться с чего-то, там флеша, диск).
Например если ноутбук поддерживает только десятку, то чтобы установить семерку, нужно не только отключить Secure Boot Mode, нужно еще включить режим совместимости с другими операционками, такая опция может называться:
- Launch CSM
- CMS Boot
- UEFI and Legacy OS
- CMS OS
Вышеперечисленная опция может находится в разделе Advanced > подраздел Boot Mode или OS Mode Selection.
Опция в биосе ASUS:
Вообще попахивает бредом.
Но думаю что корни идут например.. к процессору. Новые процы поддерживают новые инструкции, поэтому например десятка реально может работать быстрее на новом проце чем семерка.
Укрощаем UEFI SecureBoot
Если вам интересно, как сгенерировать свои собственные ключи для SecureBoot, как установить их вместо стандартных (или вместе с ними), как подписать ваш любимый EFI-загрузчик, как запретить загрузку неподписанного или подписанного чужими ключами кода, как выглядит интерфейс для настройки SecureBoot у AMI, Insyde и Phoenix и почему это, по большому счету, совершенно не важно — добро пожаловать под кат, но опасайтесь большого количества картинок и длинных консольных команд.
Введение
С ликбезом закончили, теперь к делу. Несмотря на то, что про создание своих ключей и настройку SecureBoot написано за три последних года с десяток отличных статей (ссылки на часть из которых приведены в разделе Литература), воз и ныне там. Основная проблема с информацией о настройке SecureBoot даже в англоязычном сегменте сети (не говоря уже о рунете) — большая часть статей, текстов и постов обрывается на «вот у нас теперь есть ключи в формате EFI Signature List, добавьте их зависимым от вашего вендора прошивки способом и готово». При этом сами вендоры не торопятся описывать меню настройки SecureBoot ни в документации на свои платформы для OEM'ов, ни в мануалах на конечные системы, в результате пользователь теряется на незнакомой местности и либо отключает SecureBoot, мешающий загружать его любимую OpenBSD (или что там у него), либо оставляет его на настройках по умолчанию (а чего, Windows грузится же). Именно этот последний шаг я и попытаюсь описать более подробно, но не в ущерб остальным необходимым шагам.
Тестовая конфигурация
Специально для этой статьи я достал из закромов пару не самых новых ноутбуков с прошивками на платформах Phoenix SCT и Insyde H2O, а также совершенно новую плату congatec (разработкой прошивки для которой я занят в данный момент) на платформе AMI AptioV. Встречайте, наши тестовые стенды:
1. AMI, они же "треугольные": congatec conga-TR3 @ conga-TEVAL, AMD RX-216GD (Merlin Falcon), AMI AptioV (UEFI 2.4)
2. Insyde, они же "квадратные": Acer Aspire R14 R3-471T (Quanta ZQX), Intel Core i3-4030U (Ivy Bridge), Insyde H2O (UEFI 2.3.1C)
3. Phoenix, они же "полукруглые": Dell Vostro 3360 (Quanta V07), Intel Core i7-3537U (Ivy Bridge), Phoenix SCT (UEFI 2.3.1C)
Об интерфейсах для настройки SecureBoot
На всех вышеперечисленных системах производитель заявляет о поддержке технологии UEFI SecureBoot, но интерфейс для ее настройки сильно отличается между системами. К счастью, это не очень большая проблема, поскольку для настройки SecureBoot на совместимых со спецификацией UEFI 2.3.1C (и более новых) прошивках никакого интерфейса в Setup, кроме возможности удаления текущего PK (т.е. перевода SecureBoot в так называемый Setup Mode) не требуется, а после этого можно использовать любое EFI-приложение, способное вызвать UEFI-сервис gRS->SetVariable с предоставленными пользователем данными, в том числе утилиту KeyTool.efi из пакета efitools, которая специально для управления ключами и предназначена, осталось только научиться ей пользоваться.
Тем не менее, если удобный интерфейс для настройки присутствует (у AMI он, на мой взгляд, даже удобнее KeyTool'а) — можно воспользоваться им, так что рассказывать про эти самые интерфейсы все равно придется.
Готовим плацдарм
Начнем с лирического отступления о наличии нужного софта для разных ОС. Несмотря на то, что Microsoft является одним из разработчиков технологии, в открытом доступе до сих пор отсутствуют нормальные средства для работы с ней из Windows (ключи можно сгенерировать утилитой MakeCert из Windows SDK, а для всего остального предлагается использовать HSM третьих лиц за большие деньги). Я подумывал сначала взять и написать нужную утилиту на Qt, но потому решил, что ключи и подписи каждый день генерировать не нужно, а на пару раз хватит и существующих решений. Можете попробовать переубедить меня в комментариях, если хотите.
В общем, для всего нижеперечисленного вам понадобится Linux (который можно запустить с LiveUSB, если он у вас не установлен). Для него существует целых два набора утилит для работы с SecureBoot: efitools/sbsigntool и EFIKeyGen/pesign. У меня есть положительный опыт работы с первым набором, поэтому речь пойдет именно о нем.
В итоге, кроме Linux, нам понадобятся несколько вещей:
1. Пакет openssl и одноименная утилита из него для генерирования ключевых пар и преобразования сертификатов из DER в PEM.
2. Пакет efitools, а точнее утилиты cert-to-efi-sig-list, sign-efi-sig-list для преобразования сертификатов в формат ESL и подписи файлов в этом формате, и KeyTool.efi для управления ключами системы, находящейся в SetupMode.
3. Пакет sbsigntool, а точнее утилита sbsign для подписи исполняемых файлов UEFI (т.е. загрузчиков, DXE-драйверов, OptionROM'ов и приложений для UEFI Shell) вашим ключом.
Загрузите Linux, установите вышеуказанные пакеты, откройте терминал в домашней директории и переходите к следующему шагу.
Генерируем собственные ключи для SecureBoot
Как обычно, есть несколько способов сделать что-либо, и чем мощнее используемый инструмент, тем таких способов больше. OpenSSL же как инструмент развит настолько, что кажется, что он умеет делать вообще всё, а если почитать к нему man — то и абсолютно всё остальное. Поэтому в этой статье я ограничусь непосредственной генерацией ключевых файлов, а танцы вокруг создания собственного CA оставлю на самостоятельное изучение.
Генерируем ключевые пары
Конвертируем открытые ключи в формат ESL
Теперь нужно сконвертировать открытые ключи из формата PEM в понятный UEFI SecureBoot формат ESL. Этот бинарный формат описан в спецификации UEFI (раздел 30.4.1 в текущей версии 2.5) и интересен тем, что файлы в нем можно соединять друг с другом конкатенацией, и этот факт нам еще пригодится.
Ключ -g добавляет к сгенерированному ESL-файлу GUID, в нашем случае — случайный, полученый запуском утилиты uuidgen и использованием ее вывода. Если этой утилиты у вас нет — придумывайте GUIDы сами или оставьте значение по умолчанию.
Подписываем ESL-файлы
Для правильно работы SecureBoot необходимо, чтобы PK был подписан сам собой, KEK подписан PK, а хранилища db и dbx — сответственно KEK. При этом PK не может быть несколько, а вот ситуация с несколькими KEK хоть и встречается в дикой природе, но я все же настоятельно рекомендую удалить предустановленный ключ Microsoft из KEK по простой причине — db и dbx могут быть подписаны любым ключом из хранилища KEK, т.е. если ключ MS оттуда не удалить, то у MS будет возможность управлять содержимым db и dbx, т.е. добавлять любые новые ключи или хеши в список доверенной загрузки и удалять из него существующие. На мой взгляд, это немного слишком, и если мы берем управление ключами в свои руки, то нужно делать это до конца. Ну тогда вам прямая дорога вот сюда, там в самом конце раздела 1.3.4.3 есть ссылка на сертификат Microsoft Corporation KEK CA 2011 в формате DER, из которого нужно сначала получить PEM командойзатем сконвертировать полученный PEM в ESL командой
после чего добавить получившийся файл к нашему файлу KEK.esl командой
Теперь Microsoft такой же авторизованный пользователь вашей платформы, как и вы сами, с чем я вас и поздравляю.
С другой стороны, если вы не хотите терять возможность загрузки Windows и подписанных ключом Microsoft исполняемых компонентов (к примеру, GOP-драйверов внешних видеокарт и PXE-драйверов внешних сетевых карточек), то к нашему ISK.esl надо будет добавить еще пару ключей — ключ Microsoft Windows Production CA 2011, которым MS подписывает собственные загрузчики и ключ Microsoft UEFI driver signing CA, которым подписываются компоненты третьих сторон (именно им, кстати, подписан загрузчик Shim, с помощью которого теперь стартуют разные дистрибутивы Linux, поддерживающие SecureBoot из коробки).
Последовательность та же, что и под спойлером выше. Конвертируем из DER в PEM, затем из PEM в ESL, затем добавляем к db.esl, который в конце концов надо будет подписать любым ключом из KEK:
Теперь подписываем PK самим собой:
Подписываем KEK.esl ключом PK:
Подписываем db.esl ключом KEK:
Если еще не надоело, можно добавить чего-нибудь еще в db или создать хранилище dbx, нужные команды вы теперь знаете, все дальнейшее — на ваше усмотрение.
Подписываем загрузчик
Осталось подписать какой-нибудь исполняемый файл ключом ISK, чтобы проверить работу SecureBoot после добавления ваших ключей. Для тестов я советую подписать утилиту RU.efi, она графическая и яркая, и даже издалека видно, запустилась она или нет. На самом деле, утилита эта чрезвычайно мощная и ей можно натворить немало добрых и не очень дел, поэтому после тестов лучше всего будет её удалить, и в дальнейшем подписывать только загрузчики.
В любом случае, подписываются исполняемые файлы вот такой командой:
Здесь я заодно переименовал исполняемый файл в bootx64.efi, который нужно положить в директорию /EFI/BOOT тестового USB-носителя с ФС FAT32. Для 32-битных UEFI (избавь вас рандом от работы с ними) используйте bootia32.efi и RU32.efi.
В результате вот этого всего у вас получились три файла .auth, которые нужно будет записать «как есть» в NVRAM-переменные db, KEK и PK, причем именно в таком порядке. Скопируйте все три файла в корень другого USB-носителя с ФС FAT32, на котором в качестве /EFI/BOOT/bootx64.efi выступит /usr/share/efitools/efi/KeyTool.efi (скопируйте его еще и в корень, на всякий случай) и ваш «набор укротителя SecureBoot» готов.
Укрощение строптивого
AMI AptioV
Insyde H2O
Phoenix SCT
Здесь возможностей еще меньше, и во всем меню Secure Boot Configuration на вкладке Security всего два пункта: возврат к стандартным ключам и удаление всех ключей с переводом системы в SetupMode, нам нужно как раз второе:
Затем на вкладке Boot нужно выбрать тип загрузки UEFI, включить SecureBoot, и создать загрузочную запись для KeyTool'а, иначе на этой платформе его запустить не получится:
Нажимаем Yes, выходим с сохранением изменений, перезагружаемся, нажимаем при загрузке F12, чтобы попасть в загрузочное меню, оттуда выбираем KeyTool, работа с которым описана выше. После добавления ключей и перезагрузки попытка повторного запуска KeyTool'а заканчивается вот так:
При этом установленный на той же машине Linux продолжает исправно загружаться, как и подписанная нами RU.efi, так что SecureBoot можно признать работоспособным.
Заключение
В итоге, благодаря утилитам с открытым кодом, удалось завести SecureBoot на системах с UEFI трех различных вендоров, сгенерировать свои собственные ключи и подписать ими нужные нам исполняемые файлы. Теперь загрузка платформы целиком в наших руках, но только в случае, если пароль на BIOS стойкий и не хранится открытым текстом, как у некоторых, а в реализации SecureBoot нет каких-либо известных (или еще неизвестных) дыр. Сам по себе SecureBoot — не панацея от буткитов, но с ним ситуация с безопасной загрузкой все равно намного лучше, чем без него.
Надеюсь, что материал вам поможет, и спасибо за то, что прочитали эту портянку.
Как узнать включен ли Secure Boot
Для того чтобы узнать включен ли Secure Boot на вашем компьютере можно воспользоваться средствами встроенными в Windows 10. Для этого нажмите Win-R на клавиатуре и выполните команду « msinfo32 ».
В результате должно появиться окно « Сведения о компьютере ». Здесь в строке « Режим BIOS » будет указано, в каком режиме работает BIOS – UEFI или Устаревший (Legacy), а в строке « Состояние безопасной загрузки » – состояние Secure Boot (включено или отключено).
Если у вас Secure Boot включен и все готово к установке Windows 11, то должно быть так, как на скриншоте внизу:
- Режим BIOS – UEFI;
- Состояние безопасной загрузки – Вкл.
Также возможен следующий вариант:
- Режим BIOS – UEFI;
- Состояние безопасной загрузки – Откл.
В этом случае для обновления до Windows 11 нужно будет включить безопасную загрузку в BIOS.
Еще один вариант:
- Режим BIOS – Устаревший (Legacy);
- Состояние безопасной загрузки – не поддерживается.
В этом случае возможно 2 варианта, либо у вас старый компьютер без поддержки UEFI и Secure Boot, либо в настройках BIOS включена эмуляция старого BIOS (режим совместимости). Во втором случае для обновления до Windows 11 нужно будет отключить эмуляцию старого BIOS и включить Secure Boot. Функция эмуляции обычно называется CSM (Launch Compatibility Support Module) .
Подробней в статье:
Читайте также: