Эдера спонсировала этот пост.
ИИ мчатся вперед, изменяет модели программного обеспечения, бизнес -модели и инфраструктуру. Но одна важная часть оборудования пытается не отставать. Те же графические процессоры, которые когда-то принесли нам реалистичные тени в таких играх, как «Quake III Arena» и Fluid Motion в «Counter-Strike», теперь питают машинное обучение (ML) и платформы Cloud AI. Первоначально созданный для рендеринга пикселей и эффектов освещения на высокой скорости, графические процессоры Excel при параллельной обработке. Это сделало их идеальными для иммерсивных игр и теперь делает их необходимыми для нейронных сетей.
То, что не поспешило в ногу, это безопасность графического процессора.
В то время как процессоры развивались, чтобы включить защиту, такие как разделение привилегий, виртуальная память и наблюдаемость времени выполнения, графические процессоры остаются закрепленными в философии дизайна, созданной для доверенных, однопользовательских сред. Это несоответствие создало опасные слепые пятна в современной инфраструктуре. В июне Wiz раскрыл еще один недостаток изоляции GPU, который еще больше подчеркнул, как графические процессора не имеют базовых предосторожности. Эти процессоры никогда не были созданы для обеспечения соблюдения строгих границ между рабочими нагрузками, а также для поддержки телеметрии и аудитации, которые требуется современной безопасности искусственного интеллекта.
Тем не менее, графические процессоры в настоящее время развернуты в общих средах с высокими ставками, как если бы они были закаленной инфраструктурой. Эта ложная уверенность — это именно то, что делает эту возникающую угрозу такой срочной.
Графические процессоры и процессоры созданы для того, чтобы делать совсем разные вещи
Создатели процессоров потратили десятилетия на разработку защиты, включая уровни привилегий, виртуальную память, изоляцию процесса и наблюдаемость. Дизайн графического процессора по-прежнему работает на предположениях, сделанных для однопользовательских, одноцелевых контекстов. GPU никогда не предназначался для использования по рабочим нагрузкам или защищать данные одного клиента от другого.
На архитектурном уровне графические процессоры и процессоры полностью различаются. ЦП созданы для вычислений общего назначения с сильным элементом управления по сравнению с выполнением и памятью. Они обрабатывают разнообразные задачи через небольшое количество ядер, каждая из которых способна переключаться между процессами и поддерживать изоляцию с помощью виртуальной памяти и строгих уровней привилегий.
Графические процессоры оптимизированы для пропускной способности. Они содержат тысячи простых ядер, предназначенных для выполнения одной и той же инструкции в больших наборах данных. Это делает их великолепными для рендеринга и матрицы матрицы, но вводит слепые пятна в переключении контекста и изоляции памяти. Память от одной рабочей нагрузки может сохраняться долго после того, как она заканчивается, что становится риском в общих средах. Без таблиц страниц, рандомизации памяти или границ Syscall, графические процессоры выявляются в способах, которыми процессоры нет.
Проблемы безопасности графических процессоров традиционно сосредоточены на этом отсутствии изоляции. Многие модели программирования предполагают, что драйвер безопасно управляет памятью и что пользователям доверяют. Это предположение разваливается в облаке. Один контейнер или виртуальная машина (VM) может оставлять следы данных, которые другой потенциально может получить доступ. Эти риски усугубляются тем, как непрозрачное выполнение GPU остается. Нет никаких зрелых инструментов для проверки времени выполнения или поведенческого аудита, которые ограничивают видимость и контроль.
Более скрытые риски и иллюзия безопасности
Хотя эти классические проблемы остаются, более глубокая история более срочная. Предприятия развертывают рабочие нагрузки ИИ в кластеры с графическими операциями, в то же время предполагая, что модели изоляции ЦП все еще применяются. Они не делают.
Во -первых, драйверы GPU представляют собой огромную поверхность атаки. Эти драйверы часто работают с повышенными привилегиями и управляют аппаратным доступом в разных нагрузках. Одна уязвимость может поставить под угрозу систему хоста. В отличие от процессоров, где драйверы меньше и часто абстрагируются операционной системой, драйверы графических процессоров обрабатывают планирование, память и инструкции непосредственно. Они большие, сложные и часто проприетарные, что затрудняет их аудит и патч.
Во -вторых, телеметрия от графических процессоров ограничена. Большинство инструментов сообщают, что метрики производительности, такие как использование и пропускная способность памяти, а не поведенческие сигналы. Нет эквивалента отслеживания Syscall или аудита ядра. Злоэнальная деятельность, такая как утечка ключей или соскоба данных, может произойти полностью в ядрах графических процессоров и оставаться невидимыми.
В -третьих, общие графические процессоры создают слепые пятна в многопользовательской среде. Рабочие нагрузки часто бегают назад, без каких -либо сильных гарантий того, что данные одного арендатора не подвергаются воздействию другого. Вера в то, что графические процессоры запускают только безвредную математику, скрывает тот факт, что эта математика часто включает в себя чувствительные встраивания, веса и токены. По мере того, как системы ИИ растут более сложными, ценность того, что временно живет на графическом процессоре. Игнорирование этих рисков только задерживает появление реальных эксплойтов, нацеленных на эти пробелы.
Чему нас научили Linux и контейнеры о взрослении
Linux никогда не был предназначен для обеспечения миллиардов контейнеров, работающих в облачных средах. Это началось как операционная система общего назначения, предназначенную для отдельных машин и доверенных пользователей. Поскольку это стало основой современной инфраструктуры, предположения, касающиеся изоляции, видимости и многопользовательства, больше не удерживались. За этим последовало быстрая эволюция инструментов безопасности, включая пространства имен, CGROUPS, SECCOMP и расширенную наблюдаемость. Экосистема должна была строить слои защиты вокруг ядра, который первоначально не предназначался для ношения веса облака.
Та же схема появляется с графическими процессорами. Эти процессоры были созданы для отображения графики и ускорения локальных вычислений, а не для запуска чувствительных рабочих нагрузок искусственного интеллекта от многих арендаторов на общем оборудовании. И все же это именно то, что они теперь ожидают. Как и Linux в раннюю эпоху контейнеров, архитектура графических процессоров не догнала требования современного использования. Чем раньше мы узнаем этот пробел, тем раньше мы сможем разработать защиту, которые требуют инфраструктуры ИИ. В противном случае мы будем продолжать ускоряться без гарантий, необходимых, чтобы избежать последствий.
Можете ли вы действительно доверять своей позиции в области безопасности искусственного интеллекта, если не понимаете, что происходит на уровне графического процессора?
Edera Reimagines Container Container, обеспечивая оптимизацию ресурсов для рабочих нагрузок без нарушения рабочих процессов разработчика. Мы перепроектировали основную архитектуру: решение с аппаратного обеспечения, а не программное обеспечение. Наш подход соединяет разрыв между тем, как контейнеры отправляются и как они должны работать. Узнайте больше последних из Edera Trending Stories youtube.com/thenewstack Tech Moving быстро, не пропустите эпизод. Подпишитесь на наш канал YouTube, чтобы транслировать все наши подкасты, интервью, демонстрации и многое другое. Группа подпишитесь с эскизом. Джед Салазар — полевой технический директор в Edera. Узнайте больше от Jed Salazar
