Эдера спонсировала этот пост.
Широко распространенное внедрение генеративного ИИ (Genai), основанное на инвестициях в миллиард долларов в инфраструктуру на основе графических процессоров, создает новую и невидимую поверхность атаки.
Поскольку предприятия мигрируют свою наиболее ценную интеллектуальную собственность в облачные рабочие нагрузки искусственного интеллекта, они доверяют своим платформам облачной защиты нативных приложений (CNAPPS). В то время как многие из этих инструментов являются зрелыми и сложными, они были возобновлены для процессора, ориентированного на ЦП и слепы к критическим вычислениям, которые определяют современную эру.
Ведущие поставщики безопасности успешно создали свои платформы с возможностью расширенного пакетного фильтра Berkeley (EBPF), технологии, которая превращает видимость в реальном времени в операционную систему хоста.
Тем не менее, эти решения работают посредством ядра, опосредованных событиями и слепы к операциям, происходящим на графическом процессоре. Это не незначительный разрыв в функции или что -то, что можно исправить; Это основополагающее ограничение в текущей парадигме безопасности, которое требует другого подхода и позиционирования в программном стеке.
EBPF переопределил безопасность времени выполнения
Чтобы понять гравитацию разрыва, важно оценить технологический скачок, который представляет EBPF и почему он стал бесспорным отраслевым стандартом для безопасности времени выполнения. Переезд в EBPF был не просто постепенным улучшением, а необходимым ответом на неотъемлемую нестабильность его предшественников.
В течение многих лет продукты безопасности получали глубокую видимость системы с помощью модулей ядра. Эти модули работают с самым высоким уровнем привилегий (кольцо 0), что позволяет им перехватывать системные вызовы, контролировать сетевой трафик и блокировать вредоносные процессы с конечным авторитетом. Поскольку они интегрированы непосредственно в ядро операционной системы, одна ошибка в стороннем модуле ядра, разработанной продуктами безопасности, может дестабилизировать всю систему, что приводит к печально известному «синюю экране смерти» на Windows или «панике ядра» на Linux.
Отключение краудстики в июле 2024 года обеспечила резкую, реальную демонстрацию опасностей непосредственно взаимодействовать с ядрами. Неправильное обновление компонента уровня ядра вызвало миллионы машин Windows по всему миру. Еще до этого инцидента поставщики платформ, такие как Microsoft в течение многих лет, работали над разработкой более безопасных стандартизированных API, чтобы уменьшить потребность в таких инвазивных методах.
EBPF стал решением, поскольку он позволяет разработчикам запускать небольшие программы с песочницей непосредственно в ядре Linux, но без риска нестабильности системы. Его основным инновациям является проверка в ккнеле, контрольный пункт, который анализирует код программы EBPF до его загрузки. Verifier гарантирует, что программа будет безопасна, подтверждая, что она в конечном итоге прекратится, не может получить доступ к произвольной памяти и не вызовет сбой ядра.
Эта программируемость в песочке разблокировала лучшие из обоих миров: глубокая видимость в ядра, опосредованные событиями, операции сетевых розетков, создание процессов и доступ к файловой системе без ущерба для стабильности системы.
Признавая свой потенциал, индустрия облачной безопасности быстро сплотилась вокруг EBPF в качестве нового стандарта. Лидеры рынка в области облачной безопасности, такие как Palo Alto Networks, Wiz и Crowdstrike, создали свои флагманские предложения защиты времени выполнения на основе, продавая его как ключ к безопасной, всесторонней видимости.
Это принятие в отрасли, однако, основывалось на предположении, которое в настоящее время признано недействительным из -за роста ИИ: что вся значимая вычислительная деятельность видна ядру хозяина. В то время как EBPF предоставляет мощную линзу в мире процессора, он слеп к новой вселенной вычислений, происходящей на графическом процессоре.
Черный ящик на автобусе PCIe
Отказ EBPF контролировать рабочие нагрузки GPU не является ошибкой или контролем; Это прямое следствие архитектурного дизайна современных ускоренных вычислений. GPU достигают своей производительности, работая как автономные системы, которые обходят самые опосредованные ядрами пути, на которые EBPF опирается для наблюдения.
Современный графический процессор-это не простое дополнение, которое выполняет инструкции от имени ЦП. Это высокоспециализированный, массово параллельный компьютер сам по себе. Он обладает собственным отдельным набором инструкций, такого как PTX NVIDIA, собственный сложный планировщик для управления тысячами одновременных потоков, собственная многоуровневая иерархия памяти (VRAM) и собственная логика управления, управляемую прошивкой в чип.
Код, написанный в таком рамках, как CUDA, составлен в бинарное «ядро». Этот двоичный файл не выполняется процессором хоста. Вместо этого библиотеки пространства пользователей (такие как Libcuda.so) и пакет драйверов графического процессора этого ядра и связанные с ним данные, отправляя его в GPU для выполнения. С этого момента весь вычислительный процесс полностью происходит в графическом процессоре, регулируемый его прошивкой и полностью независимым от ядра операционной системы хост.
По этим причинам существует четыре ключевых барьера, которые затрудняют добычу в среде выполнения графических процессоров.
Барьер 1: Выполнение графического процессора не является Syscall
EBPF получает свою силу от своей способности прикрепляться к крючкам в ядре, в первую очередь тех, которые связаны с системными вызовами. Когда традиционное приложение хочет выполнить действие, такое как открытие файла или отправка сетевого пакета, оно делает Syscall, создавая наблюдаемое событие.
Однако, когда хост-приложение запускает ядро Cuda на графическом процессоре, ядро хоста ОС видит только один вызов IOCTL () (вход/вывод), выполненный в драйвере GPU. Этот звонок непрозрачный; По сути, в нем говорится: «GPU, пожалуйста, запустите эту работу». Это не предоставляет никаких подробностей о том, что такое работа. Миллиарды инструкций, которые впоследствии выполняет графический процессор, память, которую он обращается к своему собственному VRAM, и сложный поток управления самой модели ИИ, не дают никаких дополнительных Syscalls, прерывания программного обеспечения или контекста ядра для мониторинга EBPF для мониторинга.
Барьер 2: боковая дверь DMA ‘обходит наблюдение за ядром
Для достижения высокой полосы пропускания, необходимой для ИИ, графические процессоры общаются с основной памятью системы хост с использованием прямых доступа к памяти (DMA). DMA позволяет графическому процессору читать и записывать данные непосредственно в системную оперативную оперативную оперативную операцию по шине PCIe, полностью обходя видимость процессора и ядра. Этот механизм необходим для производительности, поскольку он позволяет избежать накладных расходов, когда ЦП действует в качестве посредника для массовых передач данных, таких как веса модели загрузки или входные тензоры.
Однако с точки зрения безопасности DMA — это зияющая дыра в видимости. Эти операции памяти не запускают Syscalls, разломы страниц или любое другое событие, которое можно проследить существующими инструментами.
Барьер 3: стена водителя с закрытым исходным кодом
Основная точка видимости в существующих решениях зависит от того, что ядро, приготовленное с богатым набором крючков, к которому могут прикрепляться инструменты мониторинга. Собственные драйверы графических процессоров, в том числе модуль NVIDIA.KO от NVIDIA и аналогичные предложения других поставщиков, обычно распределяются в виде бинарных модулей с закрытым исходным кодом. Эти драйверы работают как черные ящики без общедоступных крючков для приборов, которые требуются для инструментов безопасности для детального понимания операций графического процессора.
В то время как некоторые возможности самоанализа существуют с помощью предоставляемых поставщиками инструментов, таких как NVIDIA-SMI, это, как правило, являются системами, основанными на опросах, которые подвергают высокого уровня счетчиков производительности, а не обеспечивают телеметрию безопасности в реальном времени, которые позволят обнаружить конкретные вредоносные поведения, аналогичные тем, что EBPF обеспечивает для других подсистем ядра.
Барьер 4: невидимая одноранговая связь
Крупномасштабное обучение ИИ включает в себя десятки, сотни или тысячи графических процессоров, работающих параллельно. Чтобы поддержать это требование, такие технологии, как библиотека коллективных коммуникаций NVIDIA (NCCL) и GPUdirect, позволяют графическим процессорам напрямую общаться друг с другом, либо через выделенные высокоскоростные соединения, такие как NVLink, или Peer-Peer по всей шине PCIE. Этот трафик никогда не проходит через процессор хоста или его основную память.
Из-за этого ядро хозяина не имеет видимости в этих передачах данных GPU в GPU, что делает невозможным для агента обнаружить угрозы, такие как утечка данных или вредоносное помехи между графическими процессорами в многопользовательской тренировочной среде.
Совокупный эффект этих барьеров заслуживает внимания, поскольку архитектурный выбор, сделанный для оптимизации графических процессоров для производительности, является именно тем, что делает их невидимыми для парадигмы безопасности, основанной на наблюдении на уровне ядра.
Edera Reimagines Container Container, обеспечивая оптимизацию ресурсов для рабочих нагрузок без нарушения рабочих процессов разработчика. Мы перепроектировали основную архитектуру: решение с аппаратного обеспечения, а не программное обеспечение. Наш подход соединяет разрыв между тем, как контейнеры отправляются и как они должны работать. Узнайте больше последних из Edera Trending Stories youtube.com/thenewstack Tech Moving быстро, не пропустите эпизод. Подпишитесь на наш канал YouTube, чтобы транслировать все наши подкасты, интервью, демонстрации и многое другое. Группа подпишитесь с эскизом. Дэн Фернандес — глава продуктов искусственного интеллекта в Edera и опытного машинного обучения, аналитики и профессионала в области кибербезопасности, специализирующихся на интеллекту, инженерии обнаружения, безопасности данных и безопасности инфраструктуры контейнеров. До прихода в Edera он запустил продукты в Chainguard … Подробнее от Дэна Фернандеса
