…и влияние добавления нуля
[Часть серии рассказов о багах компилятора GPU-шейдеров.]
[Предыдущая остановка: Imagination Technologies]
В этой статье мы сообщаем о некоторых проблемах, обнаруженных GLFuzz при применении к проприетарным драйверам Intel в системах Windows и Mac. Мы еще не тестировали драйверы Mesa для графических процессоров Intel.
Опасности добавления нуля
Возможно, вы помните из моего первого рассказа, что я пообещал изменить 14 символов, которые вызовут эту разницу в изображении:
Мы сообщали об ошибках в Intel с самого начала проекта GLFuzz, и они были очень восприимчивы. Поскольку Intel исправила ошибки, обнаруженные GLFuzz, скорость, с которой наш инструмент находит ошибки в их более поздних версиях драйверов, снизилась — это относится к любому фаззеру.
Проблема, проиллюстрированная парой изображений выше, была одной из первых, о которых мы сообщили. Это было с графическим процессором Intel HD Graphics 520 и версией драйвера 20.19.15.4326 под Windows 10.
GLFuzz обнаружил, что изменение этой строки кода:
vec3 ray = normalize(cSide * p.x + cUp * p.y + cDir * targetDepth);
to:
vec3 ray = normalize(cSide * p.x + cUp * (p + vec2(0.0)).y + cDir * targetDepth);
т. е. изменение p на (p + vec2(0.0)) привело к отображению красивого, но неправильного изображения. Интересно, что неправильное изображение чем-то похоже на неправильное изображение, которое мы рассматривали в нашей истории про ARM — вот они рядом:
Вышеупомянутая проблема добавления нуля исправлена в более поздних драйверах Intel для HD Graphics 520. Но последний драйвер версии 21.20.16.4542 демонстрирует то, что, по нашему мнению, является связанной проблемой, задокументированной этой проблемой на GitHub. Этот фрагментный шейдер приводит к рендерингу следующего изображения:
Попробуйте сами через WebGL:
На этот раз GLFuzz меняет следующую строку кода:
return ObjUnion(obj0(p), obj1(p));
to:
return ObjUnion(obj0(p + vec3(0.0, injectionSwitch.x, 0.0)), obj1(p));
Это еще один пример «добавления нуля», потому что мы установили injectionSwitch в (0,0, 0,1) во время выполнения, так что injectionSwitch.x 0,0. Таким образом, изменение не должно иметь никакого эффекта (округление по модулю с плавающей запятой).
На нашем графическом процессоре HD Graphics 520 вместо этого отображается черное изображение:
Если у вас есть аналогичная настройка графического процессора Intel, попробуйте это через WebGL:
Под Windows я получаю черное изображение с помощью Firefox и Chrome (которые используют ANGLE), а также с помощью Edge (который не использует ANGLE). Это интересно, потому что показывает, что ошибка может быть обнаружена через DirectX (напомним, что ANGLE переводит вызовы OpenGL в DirectX в Windows, поскольку это обычно более надежно, чем использование драйверов OpenGL).
Мы сообщили о проблеме в Intel.
В чем основное различие между исходным выпуском, в который мы добавили vec2(0.0, 0.0), и этим выпуском, в который мы добавили vec3(0.0, инъекцииSwitch.x, 0.0)? ?
Использование injectionSwitch означает, что компилятор не может оптимизировать добавление. Возможно, что ошибка, вызвавшая первую проблему, на самом деле не была исправлена, а скорее компилятор научился оптимизировать "+ vec2(0.0, 0.0)". Компилятор не может оптимизировать «+ vec3(0.0, инъекцияSwitch.x, 0.0)», потому что он статически не знает, какой инъекция будет храниться во время выполнения.
Больше проблем с потоком управления
Установили Windows с графическим процессором Intel Graphics HD 520 с версией драйвера 21.20.16.4542? Затем, когда вы посетите этот URL-адрес, вы, вероятно, увидите черное изображение:
когда на самом деле вы должны увидеть что-то похожее на это изображение:
Если у вас есть аналогичный графический процессор Intel, вы также можете увидеть эту ошибку, и она вполне может присутствовать в других драйверах.
Задача: исходя из наших сообщений, можете ли вы определить однострочное изменение без последствий, которое внес GLFuzz, чтобы вызвать эту проблему?
Подсказка: проблема связана с операторами, влияющими на поток управления.
Ответ: Посмотрите наш выпуск на GitHub, чтобы узнать.
Проблемы с безопасностью
Во время тестирования графических процессоров Intel мы обнаружили три проблемы, связанные с безопасностью. Мы дадим краткий обзор по ним, но с учетом ответственного раскрытия информации мы не будем давать инструкции о том, как воспроизводить! Мы сообщили об этих проблемах в Intel.
Блокировка Safari через WebGL
В этом видео Пол показывает, как рендеринг шейдеров в Safari с использованием WebGL приводит к полному зависанию системы:
Как обычно, шейдер, который он пытается отобразить, создан GLFuzz на основе написанного человеком шейдера путем применения преобразований, сохраняющих семантику. Хотя эти преобразования могут привести к большому и долго работающему шейдеру, который может пропустить крайний срок рендеринга, хотелось бы надеяться, что это не должно приводить к такому зависанию.
Глюки пользовательского интерфейса Safari через WebGL
Здесь Пол показывает, как рендеринг шейдеров, сгенерированных GLFuzz, в Safari может вызвать сбои в частях интерфейса Safari, которые находятся за пределами области рисования WebGL:
В 00:47 вы можете увидеть доказательства того, что это определенно проблема рендеринга, потому что части визуализированного изображения появляются в другом месте окна Safari.
Синий экран Windows (но не через WebGL)
В этом видео я показываю, как инъекции GLFuzz приводят к синему экрану под Windows 10:
Интересно, что желаемое изображение на самом деле отображается до появления синего экрана! Код ошибки, связанный с синим экраном, — WHEA_UNCORRECTABLE_ERROR. Согласно этой документации Microsoft: Эта проверка ошибок указывает на то, что произошла фатальная аппаратная ошибка. Мы попробовали это на двух разных машинах с графическими процессорами Intel HD Graphics 520 и получили синий экран на обоих, поэтому маловероятно, что это связано с неисправным графическим процессором.
В отличие от синего экрана, о котором мы сообщали в нашем посте об AMD, мы не смогли воспроизвести этот с помощью WebGL.
Мы весело провели время, занимаясь автоматическим сокращением этих ошибок синего экрана, что сложно и несколько нервирует! Когда-нибудь я напишу еще одну историю об этом. Но хотя мы обнаружили это и синий экран AMD с использованием очень больших вариантов шейдеров, мы смогли свести эти шейдеры к действительно небольшим примерам, вызывающим те же проблемы.
Следующая остановка: NVIDIA(но только после праздников!)
