Подробные данные для текущего релиза приведены на сайте: https://www.kaspersky.ru/enterprise-security/ngfw. Там же есть разбивка по моделям оборудования, - см. раздел «Аппаратные и виртуальные платформы»
Спасибо за уточнение. Согласен с вами, что пример про получение времени в контексте рассказа про syscall-ы неудачен. Упустил из внимания момент с vDSO-оптимизацией.
Написал небольшой benchmark, в котором сравнил скорость работы реализации из VPP и clock_gettime. Как видно из замеров ниже, реализация из VPP работает в однопоточном режиме почти в два с половиной раза быстрее, чем clock_gettime, даже с учетом vDSO. То что vDSO использовалось видно на приложенной perf трассе.
в perf-трассах видно, что реализация из VPP заинлайнилась в benchmark, что ожидаемо, т.к. она целиком находится в h файлах
если посмотреть vDSO-реализацию в исходном коде ядра:
Пакет BGP/OSPF поступает на сетевую карту и через DPDK попадает в граф узлов VPP.
Пакет проходит через наши модули в соответствии с настроенными правилами, наравне с обычным трафиком. Мы проверяем его на соответствие политикам безопасности — кто источник, разрешено ли вообще такое соединение и т.д.
После успешной проверки, через механизм TAP-интерфейсов, пакет "инжектируется" в сетевой стек ядра Linux.
Демон, работающий в пользовательском пространстве, получает этот пакет через обычный сетевой сокет, как если бы он пришел напрямую через сетевой интерфейс.
Хочу добавить, что С++ разработчики нам также очень нужны.
Общий код, используемый на разных платформах, объединен в компоненты (PDK – product development kit). Данный код разрабатывается выделенным подразделением, и используется в большинстве продуктов компании, в том числе и в Mobile продуктах. Эти компоненты пишутся преимущественно на C++.
Разработка на С/С++ ведется и внутри мобильного подразделения. У нас есть свои, специфичные для мобильных продуктов, базовые компоненты. Ряд мобильных операционных систем, таких, например, как «Аврора», поддерживают разработку исключительно на С/C++.
В связи с этим С++ разработчики востребованы во многих подразделениях ЛК, в том числе и у нас.
Более подробно про вакансию C++ разработчика под Mobile можно посмотреть тут
На Android дистрибутивы сторонних приложений, установленные на устройство, доступны на чтение для других приложений, имеется также возможность с согласия пользователя удалить эти приложения. Таким образом антивирусные приложения имеют возможность анализировать и детектировать вредоносный код в них.
Кроме того, исследовать поведение подозрительного приложения можно в специально созданной для этого контролируемой среде. Такую среду можно создать и на устройстве пользователя, но чаще дистрибутивы подозрительных приложений анализируются в специально предназначенной для этого облачной инфраструктуре.
На Android также есть API, позволяющий перехватывать трафик других приложений. С его помощью можно анализировать сетевую активность приложений, обнаруживать аномалии и сетевые атаки. Для использования этого API необходимы специальные разрешения пользователя, кроме того, одновременно его может использовать только одно приложение на устройстве. Из-за подобных ограничений используют этот API для обнаружения вредоносного ПО не часто, но, тем не менее, такая возможность на Android есть.
В случаях, когда сторонняя библиотека втягивается в SDK, к ее выбору подходим значительно более тщательно, чем при принятии такого же решения для приложения.
Библиотека втягивается только в случае, если она несет значимый функционал, самостоятельная разработка которого сложна и займет длительное время. Примером тут может быть openssl, — самостоятельно данный функционал реализовать затруднительно, и подобная реализация неизбежно будет значительно хуже оригинала.
Библиотеки, предлагающие решение какие-либо архитектурные проблем, в SDK не затягиваем.
Причин на это несколько:
— Возможные конфликты между версиями библиотек, используемых в SDK, и аналогичными библиотеками в проектах, в которые данный SDK будет встраиваться.
— Увеличение объема бинарного кода SDK.
— Появление зависимостей на сторонний код, план развития которого в будущем нами не контролируется. В качестве примера могу привести недавний коммит в код библиотеки Sqlite, полностью убравший из новых версий данной библиотеки поддержку крипто кодеков. Чем больше подобных зависимостей в проекте, тем больше вероятность того, что часть из этих внешних библиотек в какой-то момент перестанут поддерживаться их авторами. В этом случае придется их поддерживаться самостоятельно или искать какую-то замену. В случае с SDK подобные замены могут приводить к нарушению обратной совместимости и вызывать дополнительные сложности по переходу на новую версию SDK у клиентов, которые его используют.
К переходу на Target API 29, 30 уже готовы, в базовых компонентах SAF поддержан. Форсировать переход на данные Target API и, следовательно на SAF, необходимости пока нет. Но как только данный Target API станет обязательным для приложений в Google Play, готовы на него перейти. Производительно SAF в Android 11 стала лучше, чем в 10, однако, API у Google это получилось на мой взгляд достаточно корявым и неприятным.
Подробные данные для текущего релиза приведены на сайте: https://www.kaspersky.ru/enterprise-security/ngfw. Там же есть разбивка по моделям оборудования, - см. раздел «Аппаратные и виртуальные платформы»
Спасибо за уточнение. Согласен с вами, что пример про получение времени в контексте рассказа про syscall-ы неудачен. Упустил из внимания момент с vDSO-оптимизацией.
Написал небольшой benchmark, в котором сравнил скорость работы реализации из VPP и clock_gettime.
Как видно из замеров ниже, реализация из VPP работает в однопоточном режиме почти в два с половиной раза быстрее, чем clock_gettime, даже с учетом vDSO. То что vDSO использовалось видно на приложенной perf трассе.
в perf-трассах видно, что реализация из VPP заинлайнилась в benchmark, что ожидаемо, т.к. она целиком находится в h файлах
если посмотреть vDSO-реализацию в исходном коде ядра:
https://elixir.bootlin.com/linux/v6.13/source/lib/vdso/gettimeofday.c#L235
https://elixir.bootlin.com/linux/v6.13/source/lib/vdso/gettimeofday.c#L159
то бросается в глаза тот факт, что в коде присутствуют барьеры на чтение.
Для SMP сборки ядра под x64, судя по коду, такой барьер превращается в инструкцию lfence
https://elixir.bootlin.com/linux/v6.13/source/include/asm-generic/barrier.h#L103
https://elixir.bootlin.com/linux/v6.13/source/arch/x86/include/asm/barrier.h#L23
Это, в свою очередь, должно приводить к тому, что при большом количестве ядер CPU и соответствующем им количестве рабочих потоков, получающих время, скорость vDSO-реализации будет работать еще медленнее относительно реализации VPP, в которой барьеров памяти нет.
Спасибо. Да, все так.
Пакет BGP/OSPF поступает на сетевую карту и через DPDK попадает в граф узлов VPP.
Пакет проходит через наши модули в соответствии с настроенными правилами, наравне с обычным трафиком. Мы проверяем его на соответствие политикам безопасности — кто источник, разрешено ли вообще такое соединение и т.д.
После успешной проверки, через механизм TAP-интерфейсов, пакет "инжектируется" в сетевой стек ядра Linux.
Демон, работающий в пользовательском пространстве, получает этот пакет через обычный сетевой сокет, как если бы он пришел напрямую через сетевой интерфейс.
Привет!
Хочу добавить, что С++ разработчики нам также очень нужны.
Общий код, используемый на разных платформах, объединен в компоненты (PDK – product development kit). Данный код разрабатывается выделенным подразделением, и используется в большинстве продуктов компании, в том числе и в Mobile продуктах. Эти компоненты пишутся преимущественно на C++.
Разработка на С/С++ ведется и внутри мобильного подразделения. У нас есть свои, специфичные для мобильных продуктов, базовые компоненты. Ряд мобильных операционных систем, таких, например, как «Аврора», поддерживают разработку исключительно на С/C++.
В связи с этим С++ разработчики востребованы во многих подразделениях ЛК, в том числе и у нас.
Более подробно про вакансию C++ разработчика под Mobile можно посмотреть тут
Кроме того, исследовать поведение подозрительного приложения можно в специально созданной для этого контролируемой среде. Такую среду можно создать и на устройстве пользователя, но чаще дистрибутивы подозрительных приложений анализируются в специально предназначенной для этого облачной инфраструктуре.
На Android также есть API, позволяющий перехватывать трафик других приложений. С его помощью можно анализировать сетевую активность приложений, обнаруживать аномалии и сетевые атаки. Для использования этого API необходимы специальные разрешения пользователя, кроме того, одновременно его может использовать только одно приложение на устройстве. Из-за подобных ограничений используют этот API для обнаружения вредоносного ПО не часто, но, тем не менее, такая возможность на Android есть.
Библиотека втягивается только в случае, если она несет значимый функционал, самостоятельная разработка которого сложна и займет длительное время. Примером тут может быть openssl, — самостоятельно данный функционал реализовать затруднительно, и подобная реализация неизбежно будет значительно хуже оригинала.
Библиотеки, предлагающие решение какие-либо архитектурные проблем, в SDK не затягиваем.
Причин на это несколько:
— Возможные конфликты между версиями библиотек, используемых в SDK, и аналогичными библиотеками в проектах, в которые данный SDK будет встраиваться.
— Увеличение объема бинарного кода SDK.
— Появление зависимостей на сторонний код, план развития которого в будущем нами не контролируется. В качестве примера могу привести недавний коммит в код библиотеки Sqlite, полностью убравший из новых версий данной библиотеки поддержку крипто кодеков. Чем больше подобных зависимостей в проекте, тем больше вероятность того, что часть из этих внешних библиотек в какой-то момент перестанут поддерживаться их авторами. В этом случае придется их поддерживаться самостоятельно или искать какую-то замену. В случае с SDK подобные замены могут приводить к нарушению обратной совместимости и вызывать дополнительные сложности по переходу на новую версию SDK у клиентов, которые его используют.