ADD r1, r2 → SUB r1, r2). Любое отклонение от начального состояния в конце выполнения должно быть ошибкой. Реверсивный подход хорош, но он усложняет создание тестовых сценариев для архитектуры CISC, такой как x86.
В случае с Zenbleed использовался другой тестовый оракул, который назвали "сериализованный оракул". Во время фаззинга отслеживается макроархитектурное состояние, как например значения регистров. Существует также микроархитектурное состояние, которое в основном невидимо для нас, например, предсказатель ветвлений, состояние спекулятивного выполнения инструкций и конвейер инструкций. Сериализация позволяет иметь некоторый контроль над этим, указывая CPU отключить параллельное выполнение инструкций. Основная идея сериализованного оракуласостоит в том, чтобы сгенерировать случайную программу, а затем автоматически преобразовывать её в сериализованную форму. Случайно сгенерированная последовательность инструкций и та же последовательность, но с добавлением рандомизированного выравнивания (см. пример инструкций), сериализации и спекулятивных ограждений. Эти две программы могут иметь разные характеристики производительности, но они должны выдавать одинаковый результат. Если конечные состояния не совпадают, то, должно быть, была какая-то ошибка в том, как они были выполнены на уровне микроархитектуры, что может указывать на ошибку. Так Zenbleed и обнаружили - вывод сериализованного оракула не совпал.
via