Интересует следующий вопрос:
Если в инструкции используется префикс переопределения разрядности несколько раз, то каким будет конечный результат и вообще выполнима ли эта конструкция?
пример(с использованием 32bit сегмента):

67670000 add [eax],al
или
67670000 add [bx][si],al

Ни hiew ни IDA такую конструкцию не обрабатывают...

а также интересно, сбрасывается ли этот префикс, если между ним и опкодом несколько префиксов переопределения сегментов стоят?

Вопрос интересный.
Но легко выясняемый.
Код работает? Или нет?
Тут всё зависит от архитектуры проца. Сделай тест. Например такой под Win32

префикс1
префикс2
pusha (код)

-=-=-=-
Изменение регистров (старшие части + младшие)
-=-=-==-=

префикс1
префикс2
popa (код)

И так далее..

Сбрасываться не будет пока длина
инструкции не превысит 15 байтов.
(меняться тоже ничего от дублирования не будет -
это как будто ты сказал ещё раз что-то что уже до этого
сказал, или продолжаешь жать рычаг в положение выключено,
хотя уже выключено)
Из префиксов замены сегмента будет
учитываться последний.
Опять же ситуация с этим что общая длина инструкции не должна
быть больше 15 байт.
Иначе - внутреннее прерывание, особый случай 6.

Если в инструкции используется префикс переопределения разрядности несколько раз, то каким будет конечный результат и вообще выполнима ли эта конструкция?

Эта ситуация описана Касперски в своей первой книге "Техника и философия хакерских атак".

Edmond
Я как раз и проверил :) Оказалось так, как и написал The Svin... Действительно, обратного переключения режима адресации при повторении сегмента не наблюдаетя. Другой вопрос - это действительно на всех процессорах Intel (и совместимых), или специфично лишь для некоторых...

volodya
К сожалению именно про несколько идущих подряд префиксов замены адреса в этой книге ничего не сказано...

Должно на всех быть, разумеется начиная с моделей где префиксы 67\66 появились.

По этому поводу в Букварях от Intel'а и AMD сказано: "The result of using multiple prefixes from a single group is unpredictable". Это означает, что сейчас актуальным (в смысле действующим) является префикс указанный самым последним, но не факт, что завтра актуальным не станет ,к примеру, самый первый префикс

Тема, что, как, о чём и почему пишется в "букварях" Intel
была бы очень интересной, если бы нам (собеседникам) удалось удержаться от "морализаторских" оценок типа
"Врёт Intel или нет" и тому подобных.
Особено таких как "Как Intel должна себя вести" :)
Так как Intel до лампочки что мы об этом думаем,
и лучше (для нас) воспринимать её как стихию типа дождика :)

Если, Fixer, ты готов к такому разговору, в смысле обменяться мыслями и покалякать с точки зрения иследователей на эту тему, то разговор был бы полезным думаю и нам и другим.
Пока же давай просто взглянем на фразу которую ты привёл:

The result of using multiple prefixes from a single group is unpredictable.

Точное значение этой фразы "Результат использования нескольких префиксов для одной группы - непредсказуем"

Из английского текста вовсе не следует то что
ты написал:
"Это означает, что сейчас актуальным (в смысле действующим) является префикс указанный самым последним, но не факт, что завтра актуальным не станет ,к примеру, самый первый префикс"

На самом деле твоё определение довольно точно описывает реальность, но она никоим образом не эквивалента тому что
ты же привёл как слова Intel.

На самом дела Intel (в других случаях) использует и такую
форму описания, какую ты описал. Но она так и звучит.
Например для mov reg32,sreg
If the
register is a destination operand, the resulting value in the two high-order bytes of the register
is implementation dependent. For the Pentium 4, Intel Xeon, and P6 family processors, the two
high-order bytes are filled with zeros; for earlier 32-bit IA-32 processors, the two high order
bytes are undefined.

Тут у нас как бы три группы объектов.
Явления в процессоре (например работа и результат какого-то опкода, или как в нашем случае - результат дублирования префиксов)

Разные модели процессора.

И собственно сама документация Intel учитывающия
в формах описания как что в каких моделях работает.
Причём документация эта тоже написана в разные годы.

Формы могут быть такие:
1. Объяснение как работает без уточнений в каких моделях.
(вроде как можно понять, что это как раз тот случай когда
в настоящих и будущих моделях это всё работает и будет работать одинаково - ан нет :))
2. Что в таких то моделях то-то так то, а остальных (прошлых и будущих - неопределено, или не так).
3. Или просто (как во фразе Intel которую ты привёл) - то-то неопределено, или непредсказуемо.

На самом деле для случаев которые подподают по один класс
Intel то выберет форму 2а то форму 3и.
Почему? Для меня полная тайна.

Например, однажды я определил, что для всех встретившихся
мне современных процессоров (и всех процессоров которые
потом протестировали приятели из Win32asmcommunity)
команда
smsw reg32
работает анолгично
mov reg32,cr0
т.е. она не только копирует младшие 16 бит из cr0 но
и старшие.
Это ещё любопытный случай и потому, что
mov reg32,cr0 команда привилегированная
а
smsw reg32 - не привилегированная.
Я не могу ручаться, что это происходит на всех
процессорах после i486DX, но мы проверили много.
Я написал драйвер который выполнял команду
mov reg32,cr0
и передавал значение программе с CPL3
и программу которая делала запрос к драйверу за этим
и сама в свою очередь выполняла smsw reg32
Значения от драйвера и от smsw reg32 полностью совпадали
у всех тестирующих.
Intel же написала что 16 upper bits undefiend.
Почему она в случае с mov reg32, sreg
написала что в таких то моделях биты будут 0 а в других
undefiend. А в этом случае smsw написала что undefiend не
уточняя про тучу моделей где эти биты на самом деле будут
битами из cr0 - для меня полная загадка.

Продолжая развитие темы хотелось бы сообщить, что в своих сообщениях я никогда не прибегал к морализаторству. Тем более я не придерживаюсь мысли, что Intel сознательно может вводить сообщество программистов в заблуждение (какая-то "теория заговора"). Также на самом деле Intel вовсе не до лампочки до нашего сообщества, даже можно сказать, что Intel в какой-то мере идет на поводу (различные расширения типа MMX и SSE). В конце концов в этом мире существует такое понятие как конкуренция и Intel не единственная фирма выпускающая процессоры, так что она не может не прислушиваться к запросам пользователей (но только не к индивидуальным, а жаль :)).

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

По поводу команды smsw, эта команда была оставлена для совместимоти с 286 процессором, соответственно она и ведет как и должна была бы вести на нем. На 286 она может исполняться с любым CPL. Если Intel оставит полную программную совместимость своих старших моделей процессоров с младшими то так и будет дальше. Тогда тот факт что эта команда не только копирует младшие 16 бит из cr0, но и старшие можно считать фичой современных процессоров (в 286 не было 32-х разрядных регистров).

Считать то можно фичей, только Intel про эту фичи молчит,
а поскольку мы говорим о документации Intel то ещё раз отметим такой факт -
Про одни "фичи" Intel говорит - undefind для ВСЕХ моделей.
Про другие "фичи" Intel уже говорит, что в таких то моделях они присутсвуют, а в других - undefind.
Я привёл уже пример с mov reg32,sreg - Intel там конретно в Intel перечисляет в каким моделях верхние биты точно
будут забиты нулями, и уже только про оставшиеся модели
говорит undefind.
В случаях же с smsw она уже про Все модели говорит undefind.
И в случае с дублирующимися префиксами она про все модели говорит "unpredictable". Хотя мы имеем фактическую информацию, что в определённых моделях дублирующие префиксы декодируются предсказуемо. Почему Intel в этом случае не стала перечислять где они предсказуемы - ясности у меня нет. Т.е. я не вижу системы почему Intel то одну форму выберет (с перечислением в каких моделях это работает) то форму полной неопределённости.
Ещё один вопрос который меня волнует, как фирмы конкуренты
Intel'а дублируют фичи Intel'а включая все недокументированные.
Например то что smsw reg32 работает как mov reg32,cr0
не сказанно нигде и не про какие модели, я обнаружил это лично (показались до боли знакомыми старшие биты возвращённого значения) - более того одна команда привилегированная, другая - нет.
Тем не менее это имеет место и в других процессорах - конкуретнов Intel (которые тоже ни слова ни полслова об это в своей документации не пишут).
Как они срисовывают то эти "недокументированные вещи" у Intel?

The Svin По поводу недокументированных комманд смотри http://alter.tomsk.ru/nasm/nasmdocb.html

:)
Что там такого недокументированного?
Просто перечень команд которые NASM может пережевать.
Тем более разговор идёт не о недокументированных командах,
а о точности документации на документированные команды.
Или ты хочешь чтобы я этот документ на ошибки проверил?
Насколько там определённей чем у Intel написано.
Там ошибок и неопределённостей и неточностей ещё больше,
чем в последних доках Intel.
Конкретно упомянутая в этом топике smsw описана ещё хуже чем у Intel

The Svin Хорошо, попробуй поищи в и-ненте
syscall или sysret. А по поводу недокументированости
то есть к примеру такие комманды: salc, icebp, loadall
и др, что касается smsw, то работа (32 бит) этой коммады и
незащищенность ее для пользовательского режима
описанны еще в 1991 году в книге "Микропроцессор 386:
Как он работает и как работают с ним" Е.К. Александрова
это азы ассемблера, а не находка. Почитай лучше приведенную ссылку часности те комманды которые помечены UNDOC, этих комманд ты можеш и не встретить в описаниях
intel, а ругаться на то что люди собственным умом
ищут новые комманы, но к сожалению не могут их
описать лучше чем intel - нехорошо

PROFi Честно говоря я не понял в чем смысл подвоха по поводу sysret и syscall (Букварь AMD: "AMD x86-64 Architecture Programmer's Manual Volume 3 General-Purpose and System Instructions"; Publication No24594, Revision: 3.02, Date: August 2002; syscall - стр.343, sysret - стр.352) они в достаточной степени документированы, акромя того описание этих же команд можно откопать и на сайте Intel'а. Все остальные команды приводимые на указанном сайте и обозначенные как undocumented являются частными командами применимыми только к отдельным моделям процессоров их практическая польза для Вас как программиста близка к нулю.

The Svin Копирование фичей конкурирующими фирмами можно объяснить схожим подходом к схемотехнике процессоров и схожему-же их пути развития (и слава богу). Честно говоря я не совсем понимаю в чем сыр бор из-за того, что команда smsw является непривилигированной (я понимаю если-бы lmsw была-бы непривелигированной).

Ну уж не думал, что обсуждение темы будет продолжено :)

По моему, описания "unpredictable" и иже с ними Intel определяет только для того, чтобы всегда иметь возможность выйти из проблемной ситуации... В пример - приведенная выше инструкция smsw. То, что она непривелегированна, но выполняет функции привелегированной инструкции - это возможное нарушение защиты... Но пока все тихо, ситуацию менять не имеет смысла. Как только же вдруг всплывет факт применения этой инструкции для реальной атаки на системы, Intel всегда сможет поменять ситуацию, исправив работу инструкции... При этом разработчики, использовавшие ее недокументированную функциональность, шли на это на свой страх и риск, и претензий к компании иметь не могут... В такой же ситуации были (да и есть) разработчики, использующие loadall286/386 инструкции (даже та же Microsoft). Формально они работоспособны, но могут представлять опасность с точки зрения защиты, -> признавать официальными их не имеет смысла.
На счет же инструкций типа ICEBP, UMOV (да и тех же loadall), то IMHO, они документированны (об этом и сама Intel говорит, правда не в официальных документах), но информация о них доступна только по специальному запросу, и официальное их использование регламентированно только в рамках использования ICE (In-Circuit Emulators).
Есть конечно и интересные моменты не укладывающиеся в мою теорию:) Например инструкция salc должна быть признана начиная еще с пентиумов (если не еще раньше), но все никак не найдет себе место в официальной документации, в то время некоторые другие инструкции все же перешли в разряд документированных.
PROFi
[url=]http://www.amd.com/us-en/assets/content_type/white_papers_and_te ch_docs/21086.pdf[/url] Это по syscall/sysret... Вообще то информация не скрывается, просто другое дело, что эта команда не совместима с процессорами Intel (на сколько я смог найти информацию). У Inlel есть похожая - sysenter/sysexit.

Кстати вот по ходу дела и назрел вопрос: Каким тогда же образом AMD поддерживает loadall286/386, если на месте их опкодов находится syscall/sysret ?