Каковы компромиссы выполнения статического анализа исходного кода, байтового кода, машинного кода и т.д.?

Ответ 1

Каковы различные компромиссы для выполнения статического анализа на разных уровнях кода? Например, для Java, почему кто-то выполняет статический анализ исходного кода Java и байт-кода Java?

С точки зрения пользователя, я бы сказал, что, если у вас нет особо специфичных, легко формализованных свойств для анализа (таких как чистые свойства безопасности), обратитесь к инструменту, поддерживающему исходный код Java.

С точки зрения разработчика-разработчика, может быть проще работать с тем или иным уровнем. Здесь я представляю различия, которые приходят мне на ум. (Обратите внимание, что с компилятором и/или достойным декомпилятором инструмент, например, работает на одном уровне и представляет результаты на другом.)

Преимущества для исходного кода Java:

• Структурированный язык, т.е. петли и т.д. вместо произвольных переходов. (Это упрощает создание самого слабого предположения, например.)
• Вы можете сделать больше предположений в коде (программы байт-кода более выразительны).

Плюсы для байт-кода:

• Спецификация языка (семантика инструкций байткода) намного проще.
• Более "закрепленная" спецификация машины (VM)
• Вы можете расширить анализ до устаревшего кода и библиотек.
• Анализ позволяет использовать другие языки, ориентированные на JVM (Closure, Scala, JRuby...)
• Нет необходимости в сложном парсере

Преимущества для машинного кода:

• Вы проверяете, на что вы действительно загружаете CPU. (Нет необходимости использовать проверенный компилятор или проверенную виртуальную машину, если вы хотите полностью проверить цепочку.)

Современные инструменты, такие как SpeС# и т.д. (формальные диалекты методов С#), обычно проходят через промежуточный язык (BoogiePL (ближайший MSIL ни С#) в случае SpeС#), специально предназначенный для формального анализа.

Может ли выбор ограничивать или расширять различные типы анализов, которые можно выполнить?

В конце концов... нет, не совсем. Вы сталкиваетесь с теми же фундаментальными проблемами, независимо от которых (Turing complete), который вы решите проанализировать. В зависимости от того, какие свойства вы анализируете, YMMV, хотя.

Если вы в формальных методах и думаете о проведении анализа самостоятельно, я подозреваю, что вы найдете лучшую поддержку инструмента для байт-кода. Если вы являетесь пользователем или разработчиком и хотите провести анализ на своей собственной базе кода, я подозреваю, что вы получите больше преимуществ от инструментов, работающих на уровне Java-исходного кода.

Имеет ли выбор влияние на правильность анализов?

Зависит от того, что вы подразумеваете под правильностью. Статический анализ чаще всего "защитный" в том смысле, что вы не предполагаете, что все, что вы не знаете, истинно. Если вы ограничите свое внимание системами проверки sound, все они будут "одинаково правильными".

Ответ 2

IntelliJ имеет статический анализ для комментариев, например. Javadoc и имена параметров, которые недоступны в байтовом коде. например орфографические ошибки и несоответствия имени. Анализ кода гарантирует, что у вас есть номера строк и позиция в строке любой проблемы.

Преимущество анализа байтового кода заключается в том, что он намного проще и может быть всем, что вам нужно. У вас могут быть номера строк, но у вас не будет позиции. И вы можете анализировать скомпилированный код, для которого у вас нет источника, например. библиотеки.

Ответ 3

Каковы различные компромиссы для выполнения статического анализа на различные уровни кода? Например, для Java, почему кто-то выполнять статический анализ исходного кода Java по сравнению с кодом Jasmin и Java байткод?

Подумайте об этом так. Если вы получаете отрицательные результаты (результаты, указывающие или указывающие отрицательный или вредный атрибут) от Jasmin или байт-кода, что бы вы сделали с этим? Как бы вы решили, чтобы это было своевременно и экономически выгодно?

Теперь рассмотрим сценарий, в котором статический анализ исходного кода (скорее всего вашего исходного кода или кода , который вы владеете)) сообщает об отрицательном/вредоносном атрибуте, который необходим адресация?

Считаете ли вы, что вам будет труднее решать этот вредный аспект , который сопоставляется с исходным кодом, чем делать то же самое с вредным аспектом (возможно, похожим или связанным), но на этот раз сопоставлен с байт-кодом или Жасмин?

Дело в том, что 1) ожидается, что Jasmin будет однозначным представлением законного байткода и 2) что байт-код был сгенерирован компилятором bona-fide. Шансы на то, что проблема в байткоде напрямую связана с проблемой, введенной в исходный код в присутствии хорошо продуманного компилятора, очень минимальны.

Независимо от того, являются ли проблемы, обнаруженные на уровне байт-кода, результатом проблем, возникающих на уровне исходного кода или из-за неисправного компилятора/среды, эти проблемы обычно не действуют (sp?). Вы, как правило, не можете воздействовать на него, по крайней мере, не напрямую.

Проблемы, обнаруженные на уровне исходного кода, OTH, они эффективно действуют. То есть вы можете взять на себя это и исправить их (и по умозаключениям, удалив любые проблемы в байтовом коде, полученном из первого).

Есть вещи, которые могут быть обнаружены на уровне байтового кода, в частности, в контексте упаковки (т.е. упаковки ненужных библиотек). Но вряд ли вам когда-либо понадобится проверка на уровне байтового кода.

Если вы не работаете с компилятором и языковым дизайном (в данном случае с таргетингом на виртуальную машину), для эффективности и практичности: 1) вы предполагаете, что компилятор прав, и что 2) задан способ, которым JVM является spec ' ed, вы также предполагаете, что компилятор выполняет проверку во время компиляции, а JVM выполняет проверку во время выполнения.

Имеется ли выбор, ограничивающий или расширяющий различные типы анализов что нужно сделать? Влияет ли выбор на правильность анализов?Спасибо.

Как вы определяете правильность? Что такое правильность в этом контексте? И как это могло повлиять на правильность? Мы говорим о правильности на уровне системного уровня? Частичная и/или полная правильность? Правильность в отношении таких атрибутов, как справедливость, живость? Правильность самого процесса анализа? Правильность в отношении удовлетворения одного или нескольких требований?

Определите свои термины: dude:)

Независимо от этого, вы должны предположить, что компилятор делает достаточно правильный перевод вашего кода в целевой набор команд (опять же, если вы не занимаетесь разработкой компилятора/языка).

Если вы работаете в предположении, что "собственное" представление вашего кода верное (то есть оно "сопоставляется" с ним в соответствии с желаемой целевой платформой и системой типов), тогда вы сужаете область проверки вниз в исходный код для атрибутов, которые вы хотите проверить.

Ответ 4

Еще одно соображение - "абстракция потеряет информацию на высоком уровне". Мы делаем это с исходным кодом (высокий уровень), потому что нам нужно, где выражение встречается в исходном коде.

отношение источника к двоичному является очень важным в области визуализации исходного кода.