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

Статический дизассемблер неразрешим, потому что дизассемблер не может различить, является ли группа байтов кодом или данными. Пример, который вы привели, хорош: после инструкции RETN может быть еще одна подпрограмма, или это могут быть какие-то данные, а затем подпрограмма. Невозможно решить, какой из них правильный, пока вы не выполните код.

Когда код операции считывается во время фазы выборки инструкции, сам код операции кодирует инструкцию одного типа, и секвенсор уже знает, сколько байтов нужно считать из нее. Нет никакой двусмысленности. В вашем примере после извлечения C3, но перед его выполнением, ЦП настроит свой регистр EIP (указатель инструкции), чтобы прочитать то, что, по его мнению, будет следующей инструкцией (начинающейся с 0F), НО во время выполнения инструкции C3 ( которая является инструкцией RETN), EIP изменен, так как RETN — это «Возврат из подпрограммы»), поэтому она не достигнет инструкции 0F 88 52. Эта инструкция будет достигнута только в том случае, если какая-то другая часть кода перейдет к местоположению этой инструкции. Если ни один код не выполняет такой переход, то он будет считаться данными, но проблема определения, будет или не будет выполняться та или иная инструкция, не является разрешимой проблемой.

Некоторые хитрые дизассемблеры (я думаю, что IDA Pro делает это) начинают с места, где хранится код, и предполагают, что все последующие байты также являются инструкциями, ДО ТОГО, КАК не будет найден переход или возврат. Если переход найден и пункт назначения перехода известен путем чтения двоичного кода, то сканирование продолжается там. Если прыжок условный, то сканирование разветвляется на два пути: прыжок не выполнен и прыжок совершен.

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

Самый простой способ — просто прочитать один байт, декодировать его, а затем определить, является ли это полной инструкцией. Если не прочитан другой байт, при необходимости декодируйте его, а затем определите, была ли прочитана полная инструкция. Если нет, продолжайте чтение/декодирование байтов до тех пор, пока не будет прочитана вся инструкция.

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

Инструкция RET (retn) в вашем примере может быть концом функции. Функции часто заканчиваются инструкцией e RET, но это не обязательно. Функция может иметь несколько инструкций RET, ни одна из которых не находится в конце функции. Вместо этого последняя инструкция будет своего рода инструкцией JMP, которая переходит назад к некоторому месту в функции или полностью к другой функции.

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

В частности, набор инструкций x86 имеет довольно сложный формат необязательных байтов префикса, одного или нескольких байтов кода операции, одного или двух возможных байтов формы адресации, а затем возможного смещения и непосредственных байтов. Байты префикса могут быть добавлены практически к любой инструкции. Байты кода операции определяют, сколько существует байтов кода операции и может ли инструкция иметь байты операнда и непосредственные байты. Код операции может также указывать на наличие байтов смещения. Первый байт операнда определяет, есть ли второй байт операнда и есть ли байты смещения.

В Руководстве разработчика программного обеспечения для архитектур Intel 64 и IA-32 есть этот рисунок, показывающий формат инструкций x86:

Python-подобный псевдокод для декодирования инструкций x86 будет выглядеть примерно так:

# read possible prefixes

prefixes = []
while is_prefix(memory[IP]):
    prefixes.append(memory[IP))
    IP += 1

# read the opcode 

opcode = [memory[IP]]
IP += 1
while not is_opcode_complete(opcode):
    opcode.append(memory[IP])
    IP += 1

# read addressing form bytes, if any

modrm = None
addressing_form = []    
if opcode_has_modrm_byte(opcode):
    modrm = memory[IP]
    IP += 1
    if modrm_has_sib_byte(modrm):
        addressing_form = [modrm, memory[IP]]
        IP += 1
    else:
        addressing_form = [modrm]

# read displacement bytes, if any

displacement = []
if (opcode_has_displacement_bytes(opcode)
    or modrm_has_displacement_bytes(modrm)):
    length = determine_displacement_length(prefixes, opcode, modrm)
    displacement = memory[IP : IP + length]
    IP += length

# read immediate bytes, if any

immediate = []
if opcode_has_immediate_bytes(opcode):
    length = determine_immediate_length(prefixes, opcode)
    immediate = memory[IP : IP + length]
    IP += length

# the full instruction

instruction = prefixes + opcode + addressing_form + displacement + immediate

Одна важная деталь, не учтенная в приведенном выше псевдокоде, заключается в том, что длина инструкций ограничена 15 байтами. Можно создать допустимые в других отношениях инструкции x86 размером 16 байтов и более, но при выполнении такие инструкции будут генерировать исключение CPU с неопределенным кодом операции. (Есть и другие детали, которые я упустил, например, как часть кода операции может быть закодирована внутри байта Mod R/M, но я не думаю, что это влияет на длину инструкций.)

Однако процессоры x86 на самом деле не декодируют инструкции так, как я описал выше, они только декодируют инструкции, как если бы они считывали каждый байт по одному. Вместо этого современные ЦП считывают в буфер целых 15 байтов, а затем декодируют байты параллельно, обычно за один цикл. Когда он полностью декодирует инструкцию, определяя ее длину, и готов прочитать следующую инструкцию, он перемещается по оставшимся байтам в буфере, которые не были частью инструкции. Затем он считывает дополнительные байты, чтобы снова заполнить буфер до 15 байтов, и начинает декодирование следующей инструкции.

Еще одна вещь, которую современные процессоры будут делать, что не подразумевается тем, что я написал выше, - это спекулятивное выполнение инструкций. Это означает, что ЦП будет декодировать инструкции и предварительно пытаться выполнить их даже до того, как он завершит выполнение предыдущих инструкций. Это, в свою очередь, означает, что ЦП может в конечном итоге декодировать инструкции, следующие за инструкцией RET, но только если он не может определить, куда вернется RET. Поскольку при попытках декодирования и предварительного выполнения случайных данных, которые не предназначены для выполнения, могут возникнуть потери производительности, компиляторы обычно не помещают данные между функциями. Хотя они могут заполнить это пространство инструкциями NOP, которые никогда не будут выполняться, чтобы выровнять функции по соображениям производительности.

(Раньше они помещали данные только для чтения между функциями, но это было до того, как процессоры x86, которые могли спекулятивно выполнять инструкции, стали обычным явлением.)

Ваша основная проблема, по-видимому, заключается в следующем:

if the CPU can somehow know how many bytes it should read for the next instruction or basically how to interpret the next instruction, why cant we do it statically?

Проблема, описанная в статье, связана с «прыгающими» инструкциями (что означает не только jmp, но и int, ret, syscall и подобные инструкции):

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

Ваш пример начинается с инструкции jmp eax, что означает, что значение в регистре eax определяет, какая инструкция выполняется после инструкции jmp eax.

Если eax содержит адрес байта 0F, ЦП выполнит инструкцию jcc (левый случай на картинке); если он содержит адрес 88, он выполнит инструкцию mov (средний вариант на картинке); и если он содержит адрес 52, он выполнит инструкцию push (правый случай на картинке).

Поскольку вы не знаете, какое значение будет иметь eax при выполнении программы, вы не можете знать, какой из трех случаев произойдет.

(Мне сказали, что в 1980-х годах даже были коммерческие программы, в которых во время выполнения происходили разные случаи: в вашем примере это означало бы, что иногда выполняется инструкция jcc, а иногда инструкция mov!)

When we reach after C3, how does it know how many bytes it should read for the next instruction?

How does the CPU know how much it should increment the PC after executing one instruction?

C3 не является хорошим примером, потому что retn является «прыгающей» инструкцией: «инструкция после C3» никогда не будет достигнута, потому что выполнение программы продолжается в другом месте.

Однако вы можете заменить C3 другой инструкцией длиной в один байт (например, 52). В этом случае четко определено, что следующая инструкция будет начинаться с байта 0F, а не с 88 или 52.