company_banner

Защита ядра Linux из ARM Trustzone: как усилить Linux Kernel Runtime Guard и предотвращать последствия zero-day



    Всем привет! В ОС Аврора мы уделяем большое внимание обеспечению безопасности. Сегодня немного расскажем о перспективном подходе — синергии технологии ARM TrustZone и open-source проекта Linux Kernel Runtime Guard (LKRG) для повышения защищённости девайсов (в том числе от zero-day уязвимостей). Поговорим о том, что такое вообще ARM TrustZone, продукт Аврора ТЕЕ, пройдёмся по внутреннему миру LKRG и его ограничениям. Затем о том, как с использованием доверенной среды исполнения можно преодолеть эти ограничения, для того чтобы LKRG можно было рассматривать для применения в продакшене ОС.

    Cтатья была подготовлена по материалам доклада нашего коллеги Антона Рыбакова на конференции OS-DAY 2020 https://youtu.be/jjYJKZK_bas

    Итак, для начала краткое содержание:


    • О технологии ARM TrustZone и Аврора ТЕЕ
    • О проекте Linux Kernel Runtime Guard
    • Ограничения Linux Kernel Runtime Guard
    • Устранение недостатков с помощью ARM TrustZone


    Данные приложений на смартфонах представляют большой интерес для злоумышленников, так как позволяют получить доступ к важной персональной или бизнес-информации. Такими данными являются, например, содержимое банковских приложений, биометрическая информация, ключи шифрования и т.д. Для получения доступа к такой чувствительной информации могут применяться атаки, направленные на нарушение целостности ядра ОС путём эксплуатации цепочек уязвимостей, в том числе нулевого дня. Задачей комплекса мер безопасности, применяемых в операционных системах смартфонов, является предотвращение и уменьшение последствий атак.

    О технологии ARM TrustZone



    На сегодняшний день практически все SoC для мобильных устройств базируются на ARM-процессорах реализующих спецификации Cortex-A [1] ARMv7-A/v8-A [2], и, как правило, обладают поддержкой технологии ARM TrustZone [3]. Эта технология позволяет организовать доверенную среду исполнения — Trusted Execution Environment (TEE), изолированную от основной операционной системы. Доверенная среда исполнения используется для запуска приложений, требующих повышенного уровня безопасности, например — биометрической идентификации, платёжных систем и т. д. На рис. 1 представлена схема работы ARM TrustZone.

    Рисунок 1: ARM TrustZone — аппаратная изоляция сред исполнения

    ARM TrustZone основывается на аппаратном разделении ресурсов между двумя состояниями процессора — основным и доверенным. Помимо этого ARM предоставляет дополнительные IP-блоки контроллеров памяти и периферии — TrustZone Address Space Controller (TZASC) [4], а также TrustZone Protection Controller (TZPC) [5]. Эти блоки позволяют запретить доступ к определённым участкам адресного пространства или периферийным устройствам из обычного режима исполнения (основной ОС). Переключение между основным и доверенными режимами исполнения ядра процессора осуществляется путём вызова специальной инструкции — SMC (Secure Monitor Call), см. рис. 2.

    Рисунок 2: Переключение режима исполнения в ARM TrustZone

    С точки зрения архитектурного исполнения возможны различные варианты организации доверенной среды (см. рис. 3):

    • выделение одного из вычислительных ядер SoC для исполнения TEE;
    • попеременное переключение вычислительных ядер в режим доверенного исполнения по запросу;
    • вынос части функционала доверенной среды (как правило — криптографических операций) в отдельный процессор и взаимодействие с ним по внешним интерфейсам.


    Рисунок 3: Архитектурные варианты реализации ТЕЕ

    Одним из преимуществ реализации архитектурного решения ТЕЕ на основе ARM TrustZone является возможность задействования при необходимости всех аппаратных ресурсов SoC для выполнения доверенных сервисов — например, для проведения биометрической идентификации в безопасной среде. Также возможны смешанные реализации TEE вида: SoC с поддержкой ARM TrustZone и дополнительный внешний сопроцессор, который как правило используется для совершения криптографических операций.

    С точки зрения высокоуровнего взаимодействия, обмен данными между основной средой исполнения и доверенной, как правило, организуется на основе использования стандартизованного API по спецификации GlobalPlatform [6].

    Производители устройств на базе SoC с ядрами Cortex-A ARMv7/v8 предоставляют программную поддержку доверенной среды исполнения для своих устройств. В последние годы наметилась тенденция к расширению возможностей сервисов доверенной среды. В частности, типичным становится совершение платежей, распознавание отпечатков пальцев, в некоторых смартфонах в доверенной среде проводится идентификация пользователя по радужной оболочке глаза и т. д. Примерами известных ОС для функционирования в среде ARM TrustZone являются Google Trusty [7], Trustonic [8], Samsung TEEGRIS [9]. Как правило, написание сторонних приложений под эти ОС невозможно, так как вендоры мобильных устройств не предоставляют такую возможность.

    Мы в компании «Открытая мобильная платформа» занимаемся разработкой ОС «Аврора» для мобильных устройств [10]. Активно развиваемся, в настоящий момент офисы разработки открыты в Иннополисе, Москве и Санкт-Петербурге. Ведётся разработка и развитие собственного продукта для реализации функционала в среде ARM TrustZone под названием «Аврора TEE». «Аврора ТЕЕ» предоставляет приложениям из основной ОС доверенные криптографические сервисы, механизмы управления ключами и безопасного хранения данных, а также аудит основной ОС и состояния устройства в целом как один из механизмов безопасности мобильного устройства.

    Чтобы дальше было проще, кратко рассмотрим режимы исполнения процессоров архитектуры ARM Cortex-A для дальнейшего использования в сокращениях. Семейство Cortex-A ARMv8-A имеет следующий набор режимов исполнения (Exception Levels): EL0 для исполнения пользовательских программ, EL1 — для исполнения ядра основной ОС, EL2 — уровень гипервизора, EL3 — монитор безопасности для переключения между нормальным и безопасным (в ARM TrustZone) режимами исполнения, S-EL0 — для исполнения доверенных сервисов, S-EL1 — для исполнения доверенной ОС, S-EL2 — для доверенного гипервизора. Для архитектуры Cortex-A ARMv7-A набор режимов исполнения идентичен, за исключением S-EL2 (введён в спецификации ARMv8.4-A).

    Посмотрим теперь, какие задачи нам нужно решить. Считаем, что защита ОС мобильных устройств на уровне исключений EL1, а также пользовательских приложений исполняющихся на уровне EL0 ставит перед собой, кроме прочего, следующие задачи:
    • защита исполняемого кода ядра ОС на уровне EL1 от модификации в ходе применения эксплоитов, а также для предотвращения развёртывания руткитов в завершающей фазе атаки
    • защита внутренних структур и механизмов ядра на уровне EL1
    • контроль над разрешениями (credentials) исполняемых пользовательских процессов для предотвращения эксплуатации уязвимостей в приложениях уровня EL0 и повышения привилегий до уровня root.

    О проекте Linux Kernel Runtime Guard



    Многие современные механизмы защиты основываются на усилении существующих мер безопасности. Например, задействуются различные программные и программно-аппаратные механизмы — Safe Stack, Pointer Authenthication и т. д. При этом, если злоумышленник находит способ преодолеть эти механизмы, то он получает возможность дальнейшей компрометации данных без риска быть обнаруженным.

    Среди проектов для реализации мер безопасности существует проект с открытым исходным кодом, распространяемый по лицензии GPLv2 под названием Linux Kernel Runtime Guard (LKRG) [11]. Его особенностью является пост-детектирование факта совершения атаки, что позволяет обнаруживать применение эксплоитов, преодолевших традиционные механизмы защиты. Это позволяет потенциально защитить ОС от атак, механизм действия которых на настоящий момент неизвестен или от атак, эксплуатирующих уязвимости, не обнаруженные в текущее время. При этом важно отметить, что реагирование на вредоносное воздействие производится до того, как запрошенная операция будет непосредственно выполнена. Функционально LKRG состоит из 2х основных модулей — Exploit Detection (ED), для обнаружения воздействия на пользовательские процессы исполняющиеся на уровне EL0, и Integrity Timer (IT), для обнаружения воздействия на код ядра ОС уровня EL1.

    Модуль Exploit Detection контролирует пользовательские процессы. Проверка состояния их структур на входе/выходе отслеживаемых функций ядра ОС Linux позволяет обнаруживать злонамеренное повышение привилегий, в частности — подмену указателей на структуры с токенами аутентификации / разрешениями, а также перезапись этих структур, в том числе с использованием внутренних вызовов ядра; злонамеренное изменение конфигурации и правил seccomp; злонамеренное изменение пространства имён и выход за пределы контейнеров. Данный модуль LKRG также контролирует поток управления путём разворота стека вызовов при входе в отслеживаемые функции ядра, при этом происходит обнаружение использования техники Return Oriented Programming (ROP), дополнительно детектируются атаки направленные на подмену стека вызовов и передачу управления в области за пределами ядра ОС.

    Второй основной модуль LKRG, Integrity Timer, осуществляет проверку целостности непосредственно ядра ОС Linux. Отслеживается текущее состояние вычислительных ядер процессора и системных регистров, вычисляется контрольная сумма кодовой базы ядра и модулей и производится периодическая проверка на совпадение вычисленной контрольной суммы и актуального состояния. Также отслеживаются изменения в таблицах обработчиков прерываний, системных вызовов и производится контроль глобальных переменных ядра, непосредственно влияющих на обеспечение безопасности, в частности — selinux_enabled / selinux_enforcing / selinux_state и т. д.

    Рисунок 4: Функциональная схема проекта LKRG

    Схема работы LKRG представлена на рис.4. Она показывает, что в качестве источников данных используются сведения, полученные на входе/выходе из контролируемых при помощи механизма k(ret)probes функций ядра. Собранные данные при помощи модулей контролирующей логики сравниваются с ожидаемым состоянием системы, которое хранится в БД каждого из модулей. Причём, для Exploit Detection контроль происходит при наступлении каждого события, а для Integrity Timer проверка осуществляется с некоторым интервалом по срабатыванию системного таймера.

    Ограничения Linux Kernel Runtime Guard



    При наличии несомненных плюсов, у данного проекта есть также определённые недостатки:

    1. Для работы LKRG требуются отладочные механизмы k(ret)probes [12], включение которых в состав ядра ОС увеличивает поверхность атаки, так как кодовая база ядра для нормальной работы данного механизма должна иметь атрибуты страниц памяти с режимом доступа «чтение/запись/исполнение».
    2. Злоумышленник, получив доступ к исполнению кода на уровне ядра, может провести атаку непосредственно на сам механизм LKRG — модифицировать его базы данных, выявить и нейтрализовать контексты исполнения, изменить состояние системных таймеров для отключения периодической проверки модулем Integrity Timer.


    Снятие ограничений с помощью ARM TrustZone



    Решить проблему №1, связанную с включением в состав ядра ОС механизма k(ret)probes можно путём установки k(ret)probes из доверенной среды исполнения. Это даёт возможность держать кодовую базу ядра в нормальном режиме исполнения с постоянными атрибутами страниц «чтение/исполнение», а также позволяет дополнительно проконтролировать тот факт, что функция, которая является источником данных для LKRG, действительно вызвана срабатыванием исключения для установленных k(ret)probes.

    Реализуется данный механизм следующим образом: кодовая база ядра ОС общего назначения всегда имеет атрибуты страниц памяти «чтение/исполнение», при этом из доверенного режима данный регион памяти доступен в режиме «чтение/запись». Далее, при загрузке модуля LKRG в ядро и регистрации k(ret)probes для контроля функций ядра, необходимые адреса передаются в доверенную среду, и из доверенной среды происходит расстановка в области .text ядра ОС общего назначения опкодов, вызывающих исключение вида «ILLEGAL INSTRUCTION» по указанным адресам. При срабатывании исключения на уровне EL1 происходит запрос переключения в режим S-EL1 для осуществления необходимых действий. При этом, поскольку переключение производится с использованием монитора безопасности уровня EL3, возможно извлечь содержимое регистров ESR_EL1 и FAR_EL1 для того чтобы проконтролировать, что вызов был инициирован из контекста исключения вызванного исполнением «ILLEGAL INSTRUCTION» по установленному ранее адресу. Данный способ представлен на Рис. 5.

    Рисунок 5: Схема установки k(ret)probes из доверенной среды исполнения

    Устранение проблемы №2, связанной с возможностью проведения атаки на сам механизм LKRG, может быть также реализовано путём выноса части функциональных частей в доверенную среду исполнения, в частности — в ARM TrustZone.

    Так, на уровни в S-EL0/1 могут быть перенесены базы данных со сведениями об эталонном состоянии контролируемой ОС, а также контролирующая логика. Вызов системного таймера в ОС Linux для активации механизма Integrity Timer может быть заменён на прерывание из доверенного режима исполнения, инициированное срабатыванием защищённого таймера, недоступного для модификации из обычного режима. На уровне EL1 в основной ОС механизм LKRG трансформируется таким образом в агент по сбору данных для последующей обработки в доверенном режиме исполнения. При этом важно отметить, что реагирование на выявленные нарушения производится также из доверенной среды, что в свою очередь защищает от атаки непосредственно на механизм реагирования на нарушение. Схема выноса функционала LKRG в доверенную среду исполнения представлена на Рис. 6

    Рисунок 6: Вынос компонентов LKRG в доверенную среду исполнения

    Мы рассмотрели набор компонентов для защиты мобильных устройств от злонамеренного воздействия, который может быть принят для организации мер безопасности: доверенная загрузка исполняемых компонентов ( основной ОС и доверенной среды) как гарантия целостности кодовой базы, контроль ОС общего назначения с использованием модуля LKRG, и усиление защиты путём выноса функциональных частей LKRG в доверенную среду исполнения, в частности, в ARM TrustZone.

    Подробнее об операционной системе Аврора, устройствах на ее платформе, а также о ресурсах для разработчиков приложений можно узнать на сайте auroraos.ru

    P.S. Защита ОС с использованием аппаратных средств не самая простая тема для изложения, но мы старались :)

    Список использованных источников и литературы:

    [1] ARM Ltd. Sales and market share. URL: en.wikipedia.org/wiki/Arm_Ltd.#Sales_and_market_share

    [2] Arm Architecture Reference Manual Armv8, for Armv8-A architecture profile.
    URL: developer.arm.com/documentation/ddi0487/latest

    [3] TrustZone technology for Armv8-A. URL:
    developer.arm.com/ip-products/security-ip/trustzone/trustzone-for-cortex-a

    [4] About the TZASC. URL: developer.arm.com/documentation/ddi0431/c/introduction/about-the-tzasc

    [5] PrimeCell Infrastructure AMBA 3 TrustZone Protection Controller (BP147). URL: developer.arm.com/documentation/dto0015/a

    [6] Global Platform. Technology Document Library. URL: globalplatform.org/specs-library/?filter-committee=tee

    [7] Trusty TEE. URL: source.android.com/security/trusty

    [8] Trustonic TEE. URL: www.trustonic.com/technical-articles/what-is-a-trusted-execution-environment-tee

    [9] SAMSUNG TEEGRIS. URL: developer.samsung.com/teegris/overview.html

    [10] Мобильная ОС Аврора. URL: auroraos.ru

    [11] LKRG — Linux Kernel Runtime Guard. URL: www.openwall.com/lkrg

    [12] Kernel Probes (Kprobes). URL: www.kernel.org/doc/html/latest/trace/kprobes.html
    Открытая мобильная платформа
    Российская мобильная доверенная ОС Аврора

    Комментарии 22

      0
      Я бы вам посоветовал посмотреть не нарушаете ли вы чьи-то патенты на TEE, я точно знаю что Samsung регистрировал много на эту тематику (самому довелось поучаствовать)
        0
        Да, спасибо! Мы стараемся внимательно следить за патентной чистотой.
        Код Samsung Teegris закрыт, а по функционалу все Trustzone OS ± одинаковы. В статье в целом идёт речь о подходе к адаптации конкретного Open-Source решения с использованием стандартных механизмов, которые предоставляет ARM TrustZone.
          0

          QSEE не упомянута в статье. Ее интересной фишкой является поддержка сторонних реализаций TrustZone. Чем активно пользуется Самсунг в своих Qualcomm телефонах.

            0

            Действительно, реализаций TEE существует достаточно много, перечислять их все наверное нет особого смысла, так как статья в целом не обзорная по реализациям. Насчёт QSEE могу сказать, что по моим сведениям сейчас Qualcomm препятствует запуску сторонних реализаций на своих типах, позволяя разрабатывать только TA под QSEE. Third-party разработчикам от этого легче не становится, так как TA подписываются вендором смартфона, и сторонние TA вряд ли могут на это рассчитывать.


            P.S. если есть информация про запуск именно сторонних реализаций самой TrustZone OS на современных чипах Qualcomm — буду рад если поделитесь ссылкой.

              0
              >> перечислять их все наверное нет особого смысла
              Странно что была упомянута Google Trusty, стоящая на горстке Хромобуков. А массовая QSEE, наверное даже самая массовая, учитывая телефоны Samsung на Qcom и устройства Qcom Iot — оказалась пропущенной.

              >> сторонние TA вряд ли могут на это рассчитывать.
              все вендоры SoC ограничивают доступ Secure World. А Qualcomm вообще наглухо закрыла даже возможность модификации SecureWorld (я сейчас про ОС и загрузку, не про ТА) всем, кроме себя. Даже производителям телефонов нельзя.
              ТА поставляют небольшое количество производителей, и влезть в их список почти невозможно.

              >> если есть информация про запуск

              Сводим вместе:
              — Qualcomm dualsigning (sdm835+) недвусмысленно говорит о том, что никакая другая TEE запущена быть не может.
              — упоминание Trustonic в утёкших BSP. Вспоминаем что за TEE использовал самсунг до TeeGRIS.
              — Прикидываем, сколько бы стоила Самсунгу поддержка их самодеяетельности (я про Knox/RKP) для двух разных TEE
              — Думаем, почему Exynos не продаётся в US, не забываем про лицензии, CDMA, и в какой стране находится Qualcomm. Кто мог бы взвалить на себя реализацию и поддержку вложенной TEE, учитывая пред. пункты.
              — Смотрим что за файлы лежат в прошивке самсунг для Qualcomm.
                0
                Поскольку связан NDA с предыдущим работодателем, не могу прокомментировать по существу. Но если говорить в целом, то по этим причинам мы развиваем независимую от silicon-вендоров реализацию TEE OS.
                  0
                  Посмотрите, сколько лет заняло вылизывание кода у остальных вендоров. Как играючи ломали QSEE вплоть до последнего публичного эксплоита в 2015 (из HLOS), и перехода на sdm платформу в 2017 (из ABL). (Про приватные можно только догадываться, печально листая страницы на chipcode, если вы понимаете о чём я)

                  Я бы поспорил, что добавление защитных механизмов для ядра — это хорошая идея. Лучше упростите бекпортинг из mainline, и держите ядро всегда свежим. Гугл вот пришёл постепенно к этому мнению с их GKI.

                  Даже с ресурсами Samsung их RKP-поделие все эти годы успешно ломают (я лично обходил все ограничения на S8, позже другие товарищи обошли на S10/S20).

                  Кроме того, любой лишний код — это дополнительная поверхность атаки. Что наглядно продемонстрировали p0 в публикации «Mitigations are attack surface, too».

                  И никакие TEE не помогут вам с BootROM эксплоитами. Только вот железо вы не делаете, и на неуязвимый чип перейти не сможете.

                  PS: глянул я список телефонов. Беда-пичаль.
                    0

                    TEE — это не серебряная пуля. Только комплекс мер будет уменьшать риски, описанных вами угроз, в том числe аппаратно-программный secureboot.
                    Мы готовы поддержать доверенное железо партнёров, например работаем с отечественными silicon вендорами.

                      0
                      кстати, о secureboot.
                      1) sailfish телефоны вычеркнуты из Авроры потому что у вас нет вендорских ключей? (а, стало быть, секуребут не включить) Например обе Xperia — самое интересное по железу, что у вас было.

                      2) Те, оба-два телефона, что доступны к покупке — вы получаете от китайских ODM с непрожжёными фьюзами? Или же они уже всё прожгли, и поделились с вами приватным ключом? (это очень важное различие!)
                        0

                        Ну, во-первых, Sailfish и Аврора как дистрибутивы различаются, и все дальше расходятся. Во-вторых, наши заказчики не готовы покупать дорогие телефоны Sony для персонала в поле (например, работник склада), во всяком случае пока более востребованы недорогие устройства с поддержкой. Некоторые модели производятся вообще в РФ и это не отверточная сборка — в СМИ были репортажи с линий, будет интересно, гляньте, около полугода назад. А по secureboot настолько большая тема, что лучше напишем статью на Хабр!

                          0
                          >> наши заказчики не готовы покупать дорогие телефоны Sony для персонала в поле

                          Смешно. Телефон на древнем msm8940 за 110 тысяч они покупать готовы, а Сони (которой сегодня тысяч 10 цена по железу) — дорого.

                          >> Некоторые модели производятся вообще в РФ и это не отверточная сборка

                          И они получаются дешевле китайских? (заказчики не готовы покупать дорогие). Не верю (ц)

                          >> СМИ были репортажи с линий, будет интересно, гляньте, около полугода назад.

                          где глянуть-то?

                          >> А по secureboot настолько большая тема, что лучше напишем статью на Хабр!

                          Меня не интересует статья. Достаточно коротких ответов да-да/нет-нет.
                            0
                            Кто-то готов, а кто-то нет, поэтому есть разные модели разных производителей/компаний с разной ценовой политикой. Мы производители ПО, а не железа.
                            Если вы когда-либо занимались secureboot, то должны понимать почему «да-да/нет-нет» тут не работает: у разных аппаратных платформ разная модель корня доверия. Поэтому мы лучше напишем статью, чтобы был контекст.
                              0
                              Господи. У вас всего лишь два телефона продаётся. Один на MTK, второй на Qualcomm. Корень доверия там одинаковый, OTP фьюзы + MaskROM PBL.

                              Судя по всему, доступа к фьюзам вы не имеете. Поэтому и уклоняетесь с ответом.
                        0
                        >> Мы готовы поддержать доверенное железо партнёров

                        Каких, например?
                        И как быть с Qualcomm и double-sign. Вам, по-факту, недоступны процессоры, архитектурно свежее 2016 года.

                        >> например работаем с отечественными silicon вендорами.

                        Хорошая шутка.
                        Даже последний PinePhone получился изрядным *****. Хотя там используются буржуйские более-менее современные компоненты.
                          0
                          Поверьте, у нас в стране есть и разработчики SoC на ARM и даже разработчики ip-блоков, и даже разработчики архитектур (ISA). Все ли чипы являются мобильными -нет, используются ли спецификации/лицензированные блоки — да, льются ли они на зарубежных фабриках (кто-то и у нас). Кто-то могут сделать и спроектировать сами, где-то нужно покупать, чип памяти например.
                          В Pinephone используется long-term индастриал чип с 10-летним выпуском и этим он хорош
                            0
                            >> Поверьте, у нас в стране есть и разработчики SoC на ARM

                            охотно верю

                            >> Все ли чипы являются мобильными -нет

                            тоже верно, скорее даже никакие не являются

                            >> В Pinephone используется long-term индастриал чип с 10-летним выпуском

                            Вы о Qualcomm в модеме или о Allwinner для HLOS?
                            В любом случае, нашим «аналогам» до них — как раком до луны, особенно до Qualcomm.

                            >> и этим он хорош

                            Не надо рассказывать мне сказок. У меня PinePhone есть в наличии. Самая жирная модель с 3Gb. Стоковая прошивка октября 2020. Полное ###но. Практически по всем пунктам (лень расписывать каждый). Да, концептуально он хорош. Да, возможно софтово всё решаемо. И может быть ещё через 1-3-5-10 лет разработчики допилят прошивку. Но по-факту, здесь и сейчас, на выходе имеем кусок чего-то, а не телефон.

                            С другой стороны, это честный телефон. По честной цене (1/10 от ваших телефонов), честно разработанный самостоятельно (без гос. поддержки), честно открытый — без вендор-локов. И без вранья про супер-безопасность.
          0
          Почему на сайте sailfish последний дроп исходников был аж полтора года назад?
          Выложена версия 3.1.0.11, от 22 окт 2019,
          тогда как актуальная у sailfish/aurora сегодня 3.4.0, от 13 окт 2020

          Почему сертифицированная аврора имеет версию 3.2.2 (отстаёт от основной почти на год), и такой версии нет среди версий sailfish?

          Почему бюллетень безопасности всего один, за сентябро-октябрь 2020. Очень короткий. А баги, закрытые в нём, датируются аж 2008 и 2017 годами(!!!). (посмотрел всего две, очень удивился датам)

          Как только скачать исходники, а не целиком весь SDK? Вообще хотелось бы иметь GIT доступ в реальном времени, по-типу AOSP.
            0
            Очень приятно, что есть такое внимание к нашей работе!
            > Почему на сайте sailfish последний дроп исходников был аж полтора года назад?
            Не знаю, это вопрос к другой компании

            Sailfish и Аврора это разные дистрибутивы, у них есть общая история и есть некоторые общие компоненты опять же в силу истории, но релизные циклы разнятся, как и фичи/компоненты, как и процесс производства.
            Именно поэтому, как вы верно заметили, есть Аврора 3.2.2. Актуальную информацию по релизам Авроры можно посмотреть на auroraos.ru. Мы будем развивать этот ресурс, и обновлять информацию, в том числе по CVE.
            Далеко не все компоненты ОС Аврора являются открытыми. А вы хотели бы контрибьютить в компоненты? Что-то вложили в AOSP?
              0
              >> Мы будем развивать этот ресурс, и обновлять информацию, в том числе по CVE.

              Но как так вышло, что сертификат безопасности ФСТЭК России №4220 вы получили 10.02.2020, а 13-летние баги стали исправлять спустя почти год?

              >> Далеко не все компоненты ОС Аврора являются открытыми.

              Всё что GPL и было публично выпущено — вы обязаны предоставить по запросу.
              Кстати, пользуясь случаем, публично запрашиваю архивы исходников всех выпущенных Linux ядер для всех созданных устройств.
              Опубликуйте, пожалуйста, ссылки для скачивания, в вашем ответе мне.

              >> А вы хотели бы контрибьютить в компоненты?

              Нет.

              >> Что-то вложили в AOSP?

              А вы?
            0
            (мимо)
              0
              Смотрите, вы купили новую машину, получили на нее сертификат, тех паспорт итд, потом решили что не хватает спойлера, добавили спойлер, а оказалось что спойлер бракованный, и эта партия спойлеров уже 13 лет как бракованная, но он вам нужен, вы его починили и обновили тех. паспорт. Примерно так.
              В AOSP лично я не котрибьютил, в Linux ядро контрибьютил, если вы лично про меня спрашивали.
              Просто вы интересовались git, я думал вы разработчик и интересуетесь по существу.
              Мне кажется вы упускаете важную деталь в GPL лицензии.
                0
                Ненавижу ложные аналогии.

                >> потом решили что не хватает спойлера, добавили спойлер

                Точно добавили? А то вдруг он всегда там был… Это же легко проверяется.

                >> а оказалось что спойлер бракованный, и эта партия спойлеров уже 13 лет как бракованная,

                Угу может оторваться и убить кого-нибудь.
                И не только спойлер. Ещё и руль 4 года бракованный, и тормоза. И бог ещё весть что, если копнуть по-серъёзному.

                >> но он вам нужен, вы его починили и обновили тех. паспорт.

                Обновили? И какой теперь номер сертификата?

                >> Просто вы интересовались git, я думал вы разработчик и интересуетесь по существу.

                Но задали-то вы другой вопрос. Нет, я не хочу разививать ваши компоненты. Да, я хочу посмотреть что и как у вас происходит.

                >> Мне кажется вы упускаете важную деталь в GPL лицензии.

                Верно. Вы можете заявить, что к каждому телефону прикладываете полную копию всех GPL исходников (п3.а). Это проверить для меня невозможно, и придётся «джентльменам верить на слово».

                В то же время другие производители не жонглируют пунктами лиценции, а просто открывают код превентивно (Google, Sony, Samsung, Xiaomi, Nokia etc.), или же по-запросу (п.3.b). Даже ZTE, даже к своему прототипу, который использовался только для внутреннего тестирорования и никогда не поступал в розничную продажу. После первого же обращения выложила код ядра на GitHub. Не спрашивая никаких доказательств, что этот прототип действительно есть на руках (впрочем он был, и не один).

            Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

            Самое читаемое