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

сегменты

> То, что с сегментами работать логичнее, по идее, должно упрощать
блин, сколько моджно об одном и том же - а самому головой подумать нельзя?
основная проблема сегментной адресации памяти - фрагментация (что-то аналогичное FAT если Вам так понятнее)
сегментая организцаия была первой которую придумали
именно из-за фрагментации от неё потихоньку отказалаись.

Это сильно! Вот только слово "аппаратно" немного обманывает. Ведь кол-во тактов проца для смены сегментов, увы, великовато, чтобы сделать эту модель практической. Соббсно, почему я и сдался на слове far.

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

> Мысль про недоделанность страничной адресации в 86 мне не очень
> понятна. Можно поподробнее?
Опа! И это после того, как Murr и анонимусы распинались как в этом,
так и в десятке других тредов на LOR об этом? Не хотелось повторять
то, что уже все тысячу говорилось, но почему бы и нет.
И так, страница имеет бит U, от слова User. Этот бит говорит только
о том, доступна ли эта страница для пользовательского процесса, т.е.
фактически доступна ли она для 3-го кольца защиты. Это бред. Нужно
ведь было всего 2 бита чтобы сделать аналог DPL для сегментов, т.е.
чтобы можно было указать необходимый уровень привелегий для доступа
к этой странице. Сэкономили 1 бит, но в результате сделали так, что
из 4-х колец защиты эффективно использовать можно только 2.
Далее... Есть бит W - разрешение на запись. Бита разрешения на чтение
нету! Чтение всегда разрешено. Бита разрешения исполнения нету тоже.
Вот так то.
В результате смотрим, например, сюда:
http://pax.grsecurity.net/docs/noexec.txt
и видим:
---
The first feature NOEXEC implements is the executable semantics on memory
pages. On architectures where the Memory Management Unit (MMU) has direct
support for this we can trivially make use of it. The main and (so far)
only exception is IA-32 where we have to resort to some tricks to get true
non-executable pages.
---

Достаточно подробно?

> Крупноблочное управление правами эффективнее в
> некоторых случаях.
В *некоторых случаях*! Это при том, что "крупноблочное" управление
всегда можно свести к "мелкоблочному", а вот наоборот - никак или
гемор. Пример вам приводили уже.

> Ведь даже в файловой системе пользователю часто удобно установить
> права на каталог один раз, чем на все файлы индивидуально
Вы будете сами себе противоречить, или же будете утверждать, что
если пользователю *иногда* удобнее установить права сразу для многих
файлов, то настройка индивидуальных прав ему вообще не нужна?

> Да я уже договорился, что не денемся. Вопрос, нельзя ли сделать крупноблочную выдачу прав на основании сегментов как основу - а права для страниц как ..
> доп. механизм, что ли. С т.зр. ОС, я имею ввиду.
Ага, 2 независимых механизма защиты вместо одного, и только ради того,
чтобы немного оптимизировать операции с крупными массивами страниц...
Ну вы хоть не на долго мысленно поставьте себя на место разработчика
прежде чем такое предлагать... :)

> Насколько я знаю, все-таки нынешние компиляторы для 86 поддерживают
> far - и ничего, никто не умер. Просто в 99% случаев можно обходиться
> near - и все счастливы - и компилятору просто, и проги быстры.
Товарищ, вы на редкость не внимательны сегодня. Я уже говорил, что
все обходятся near только по тому, что везде используется flat!

> Вообще, я тут еще немного подумал (пока поставку заказчику делал:)...
> Если мы хотим защиту на уровне сегментов (как я говорил ранее) -
> действительно, похоже, нужно делать CS != DS, а это приведет к тому,
> что указатели _по_умолчанию_ придется делать far.
Ага, таки пробило! После того, как это вам дважды сказали, вы ещё,
оказывается, "немного подумали" и сами к этому пришли:) Что ж, у
каждого свой подход к диалогу. Полагаю, это из-за того, что мы
анонимусы, вы предпочитаете доходить самостоятельно до того, что
мы вам объясняем? :)
Вообще задолбался я постить об этом. Всё равно недели через 2 те же
самые люди поднимут этот же спор. Eugene_Korobko это всё уже много
раз объясняли, но воз и ныне там.

>>> нужно делать CS != DS, а это приведет к тому ...

Никчему это, батенька, не приведет, абсолютно ни к чему.

Шире попы - не пукнешь. Указатели один хрен останутся 32битными, как и в случае flat модели. Открою вам страшную тайну - в рамках gcc,linux,x86 - вы вообще никогда не выползите за пределы 32бит юзер спэйса.

При CS != DS, Вы ,в идеале, получите гарвардскую архитектуру - 4ре гига под код и сколько же под данные.

ЗЫ прежде чем громогласно о чем либо спорить - поэкспериментируйте 8)

> При CS != DS, Вы ,в идеале, получите гарвардскую архитектуру - 4ре гига под код и сколько же под данные.
Я думаю, под CS != DS svu имел ввиду не то, что селекторы различаться,
а то, что различаются ещё и базы этих сегментов, и вообще что они не
пересекаются. Просто он выразился не точно (как я уже сказал, он
сегодня крайне невнимателен:)
svu, я вас правельно понял? А то иначе и правда получится, что мы
непонятно о чём спорим:)

> Вы ,в идеале, получите гарвардскую архитектуру - 4ре гига под код и сколько же под данные.
Кстати, если говорить про гарвардскую архитектуру, где сегменты и
правда не пересекаются, то вы утверждаете, что я могу в каждом
сегменте получить по 4Гб, и при этом их линейные адреса не будут
пересекаться?
Я утверждаю что это не так. Мой аргумент: само линейное пространство
под х86 - 4Гб. Следовательно на него нельзя отобразить несколько
сегментов по 4Гб так, чтобы они не пересекались.
Попробуйте опровергнуть, интересно, может я и не прав.

Да проблема, вобщемто, даже не в этом - достаточно посмотреть на указатель возращаемый alloc/malloc ...

>>>Попробуйте опровергнуть, интересно, может я и не прав.

Конечно - НЕ ПРАВ.

Этот действо, кстати, регулярно производится при запуске любой задачи.

> действительно, похоже, нужно делать CS != DS, а это приведет к тому,
> что указатели _по_умолчанию_ придется делать far.
Кстати да, анонимус прав. Вы (svu) выразились слишком некорректно, и
зря я стал из контекста пытаться выяснить, что вы имели введу.
Несмотря на flat модель, CS != DS в Linux! См. __USER_CS/__USER_DS
и __KERNEL_CS/__KERNEL_DS в /usr/include/asm/segment.h.
Просто у них совпадают базы и предел.
Выражайтесь точнее в следующий раз, а то ведь можно до такого
договориться...

>>>>Попробуйте опровергнуть, интересно, может я и не прав.
> Конечно - НЕ ПРАВ.
> Этот действо, кстати, регулярно производится при запуске любой задачи.
"При запуске любой задачи", а точнее, при переключении процессов,
происходит, насколько я знаю, смена каталога страниц. Мы же говорим
о сегментах в пределах одного процесса (man modify_ldt например).
Ещё раз: докажите мне, что один и тот же процесс может создать
несколько сегментов по 4Гб, линейные адреса которых не будут
пересекаться. Я полагаю, вам это не удастся.

Как раз виртуальная память и решает вышеуказанную проблему - естественно что впереть несколько сегметнтов по 4гига невозможно в те же 4ре гига адрессного пространства - но по частям они присутсвовать вполне могут - понадобилась другая страничка - свопится старая и подсасывается новая.

Спасибо за разъяснения. Таперича понятно. Только внятного объяснения проблем страничной адресации (на уровне Вашего) до 2030МСК в этот треде я не видел. Невнимательность, однако:)

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

А я и не пытаюсь это сказать - на х86+linux - 4ре гига потолок. Однако это не ограничение х86 архитектуры.

Ну что же Вы так горячитесь? Вы прямо как личное оскорбление воспринимаете некоторую ... задумчивость :) собеседника.

Да, а информацию от анонимусов действительно воспринимаю "по умолчанию" в штыки. Не люблю анонимусов, не доверяю человеку, прячущему лицо.

> Про флаги записи, чтения и noexec - понятно, но зачем Вам 4 уровня защиты - если не секрет???
Надо. Да, мне лично было нужно. Но о том, зачем это было нужно мне,
распространяться не буду. Вместо этого прочитайте, например, вот это:
http://lwn.net/Articles/13868/?format=printable

> Унихи традиционно обходятся двумя уровнями. Вроде,
> винюки тоже (хотя тут я уверен меньше). Так что на этом месте
> проблема кажется высосанной из пальца.
Да что ж такое, опять причину со следствием путаете? По тому и
обходятся, что в х86 по-другому не получится! Если бы было можно,
ещё как пользовались бы.

> Как раз виртуальная память и решает вышеуказанную проблему - естественно что впереть несколько сегметнтов по 4гига невозможно в те же 4ре гига
> адрессного пространства - но по частям они присутсвовать вполне могут - понадобилась другая страничка - свопится старая и подсасывается новая.
А вот как раз и нет. Несмотря на виртуальную память, линейное пр-во
всё равно ограничено 4Гб, и по этому такие сегменты вам не удастся
просто создать, не только что использовать. По частям или нет - это
всё не то, вы их просто создать не сможете. Вирт. память не причём тут.

ПравИльно меня поняли:) Ну, почти. Соббсно, меня даже интересовало не то, равны ли базы, а то, что указатели _должны_ содержать в себе селектор сегмента - и при этом указатель на функцию должен иметь селектор, отличный от указателя на какие-нибудь данные. В этом вопросе я даже не очень думал, как между собой физически соотносятся базовые адреса сегментов - главное, что их тождество не гарантировано ОС, т.е. нельзя обойтись near указателями. Вот что я имел в виду.

Ладно, мужики, - фигня всё это - пошел пить водку...

ВСЕХ С НАСТУПАЮЩИМ СТАРЫМ НОВЫМ ГОДОМ !!!!

> А я и не пытаюсь это сказать - на х86+linux - 4ре гига потолок. Однако это не ограничение х86 архитектуры.
Это именно что ограничение х86 архитектуры - 4Гб линейного адресного
пр-ва и не более того. Я не говорю про всякие PAE, это лишь навороты.

>>>Несмотря на виртуальную память, линейное пр-во всё равно ограничено 4Гб.

Глубоко ошибочное и к сожалению широко распространенное мнение.

Линейное простраство в смысле RAM (сиречь линейный адресс) != линейному пространству в смысле сегментного смещения.

>>>> Несмотря на виртуальную память, линейное пр-во всё равно ограничено 4Гб.
> Глубоко ошибочное и к сожалению широко распространенное мнение.
Не понял... Это 32-разрядная архитектура, а значит адресовать более
4Гб линейных адресов ей слабо. Нет? Тогда подтвердите ссылками или
чёткими доводами/объяснениями.

> Линейное простраство в смысле RAM
Опять не понял... Линейное пространство есть линейное адресное
пространство, а RAM - это уже физическое адресное пространство.

> (сиречь линейный адресс) != линейному пространству в смысле сегментного смещения.
Что за... Давайте пользоваться общепринятой терминологией, а не
изобретать свою. Есть понятие "физический адрес", "линейный адрес"
и "смещение". Когда я эти понятия путал? Не припоминаю...

Кстати не понятно, это разные анонимусы или один? А то такие стройные
ряды были, "стояли насмерть" против svu и Eugene_Korobko, а теперь
какие-то внутренние распри пошли непонятно на какой почве... :))

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

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

Кстати, а сколько уровней защиты в Спарке? В Альфе? В PA-RISC?

> Для "повседневных" задач и классических применений я не очень вижу смысл во всех этих
> наворотах. Возможно, недостаток фантазии:)
Смотря насколько "повседневных". Wine, насколько я знаю, запускает
виндовые проги в одном адресном пространстве со своим wine-client.
Этот wine-client, насколько я знаю (только по-наслышке, может и
ошибаюсь) предоставляет виндовой проге WinAPI и ещё общается с
wine-server'ом. Так вот, скорее всего виндовая прога при таком
раскладе имеет полный доступ к адр. пр-ву своего wine-client'а и
может его "испортить". С помощью доп. колец защиты, их можно было
бы изолировать.
С dosemu та же история: программы защищённого режима исполняются в
одном адр. пр-ве с самим досему, и по этому он всегда считался дырой
в защите системы, пока не стал без рутовых прав работать. Там тоже
можно было бы посадить сам досему на кольцо 2, а ДОСовая DPMI-прога
исполнялась бы на третьем.
Я думаю, примеры ещё есть, но скорее всего да, это не совсем
"повседневные" случаи. Однако и ими пренебрегать нельзя.

> > Унихи традиционно обходятся двумя уровнями. Вроде, винюки тоже
> > (хотя тут я уверен меньше). Так что на этом месте проблема
> > кажется высосанной из пальца.
>
> Да что ж такое, опять причину со следствием путаете? По тому и
> обходятся, что в х86 по-другому не получится! Если бы было можно,
> ещё как пользовались бы.

По моему UNIX не только и не столько на x86 существует.

сегменты

> расскажите, при чем тут фрагментация - сегменты-то архитектурно
> работают над страницами
да, но выделение страниц в сегмент при произвольной адресации всё равно нужно где-то хранить - получается ненужный доп. уровень с потерями как памяти (на хранение табличек) так и скорости за счёт лишнего преобразования. Нормальному MMU достаточно страничной организации. если же использовать "чистую" модель - упираемся в фрагментацию - изначально выделили 1 размер но понадобился другой размер - можно либо иметь набор разных фиксированных и выбирать под-ий каждый раз (если они, конечно, есть такие) либо пытаться увеливать имеющися - т.е. предсказать где и как будет расти.

> По моему UNIX не только и не столько на x86 существует.
Да разумеется...
Просто вся эта петрушка на счёт колец защиты пошла из-за того,
что изначально Intel сделала их 4, но потом сделала так, что
реально использовать можно было только 2. Это всё же не очень
хорошо о них говорит. Либо делать нормально, либо уж никак.
А было бы их 4 полноценных - хуже бы никому не стало, а лучше
кое-кому стало бы. Примеры я уже приводил.

Конечно же, я всю дорогу имел в виду двухуровневую модель. Чисто сегментная действительно отфрагментирует всю память вусмерть. А потери памяти на хранение таблиц - ерунда. Скорость, наверное, должна упасть - но это еще померять надо (и еще придумать, как:). Нет, киллер сегментов - это указатели:)

> Не понял... Это 32-разрядная архитектура, а значит адресовать более 4Гб линейных адресов ей слабо. Нет?

> Не понял... Это 32-разрядная архитектура, а значит адресовать более 4Гб линейных адресов ей слабо. Нет?

Нет.

Хотя я не тот Анонимус, которому адресовалось это замечание, все же позволю с Вами не согласиться. На самом деле даже 32-х разрядная архитектура процессоров Intel позволяет адресовать значительно более 4 ГБ физической памяти (т.е. RАМ). Для этого существует The Physical Address Extension (PAE) Paging Mechanism. Он был впервые представлен в Pentium Pro. Кроме того, начиная с Pentium III, можно использовать Page Size Extension. Оба эти механизма позволяют адресовать 64 ГБ физической памяти. Конечно это костыли, но то, что вы о них не слышали - это вовсе не означает , что они не существуют.

по поводу расшаривания сегментов между процессами и размеров линейного адрессного пространства - не путайте разные вещи

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

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

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

> Конечно это костыли, но то, что вы о них не слышали - это вовсе не означает , что они не существуют.
Кто сказал, что не слышал? Прочитайте сообщение anonymous (*) (13.01.2004 23:39:37),
это моё.
Только это всё не то. Указатели всё равно 32-разрядные, и засунуть в
такой указатель адрес >4Гб вам всё равно не удастся, либо скажите как.

> если процессы должны шарить сегменты это еще не значит что это должен быть один и тот же логический сегмент - каждый процесс может иметь свой
> логический сегмент со своими правами доступа, которые отображаются на одни и те же физические страницы
Ну и что? И почему обязательно сегменты? Разумеется несколько
процессов могут создать маппинг на одни и те же физические адреса.
Только к чему вы это?

> ограничение в 4 гига есть только на размер сегмента
На размер линейного адресного пространства в первую очередь.

> но не не физическое адресное пространстве
Вы физическое и линейное адресное пространство различаете? Я говорил
про ограничение на линейное адресное пространство. Вы мне уже во
второй раз пытаетесь приписать утверждение об ограничении физического
адресного пространства, а ведь я этого не говорил. Разницу между
линейными и физическими адресами почуствуйте наконец и не приписывайте
мне то, чего я не говорил:)

> вы просто по привычке продолжаете думать что адресное
> пространство обязательно должно быть линейным
Отлично... Теперь вы мои мысли читать будете... Может ещё и покажете
где я такую чушь сказал?

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

> если вам кажется что этот механизм потребует очень много памяти для
> хранения таблиц сегментов, то вы ошибаетесь - потому что таблицы двухуровневые
Ну это уже слишком... Двухуровневые таблицы хранения сегментов...
Это таблицы страниц двухуровневыми могут быть, а "таблица сегментов" -
это придуманный вами бред. Есть таблица дескрипторов - LDT или GDT.
Никакой двухуровневости там, разумеется, нет.
Короче... а ведь всё так хорошо начиналось...

>>>указатель адрес >4Гб вам всё равно не удастся, либо скажите как.

Естественно неудастся.

Однако при адресации типа ES:EDX,DS:EBX возможна аресация двух сегментов, каждый из которых имеет размер в 4ре гига итого 8 гиг.

Для особо недоверчивых - поройтесь на intel.com - там гдето валялась демонстрационная прожка распределявшая под досом 16 гиг виртуального адрессного пространсва.

> Однако при адресации типа ES:EDX,DS:EBX возможна аресация двух
> сегментов, каждый из которых имеет размер в 4ре гига итого 8 гиг.
Т.е. у второго сегмента база должна быть 0xffffffff и предел тоже?
И, значит, только отказом от flat-модели можно это заюзать?
Ну хорошо, а дальше, после 8Гб как?

> Для особо недоверчивых - поройтесь на intel.com
Да верю, верю. Я уже говорил на счёт PAE и прочих наворотов. Они в
пентах появились, а мы классику обсуждаем. В реальном режиме тоже
можно было 4 гига адресовать - так называемый Big Real Mode, или с
помощью loadall... Да чего только не было, но это всё лишь костыли
и навороты.

>>>Ну хорошо, а дальше, после 8Гб как

Да точно также.

Меняешь базу у любого сегментного регистра и вперед с песнями.

Кстати, пример там не использует никаких наворотов типа 36 бит адрессов.

Так что классика полнейшая.

> Меняешь базу у любого сегментного регистра и вперед с песнями.
А на что меняешь то? В стандартном дескрипторе под базу только
32 разряда отводятся, и не понятно как использовать больше.

> Кстати, пример там не использует никаких наворотов типа 36 бит адрессов.
> Так что классика полнейшая.
Ну может тогда ещё и ссылку? Не может оно быть без наворотов,
стандартными средствами такого не сделать.

Зы - В догонку "Навороты" служат едиственной цели - увеличить обьем реальной физической памяти (>4GB) и снизить затраты на свопинг, но никоим раком они не относятся к обсасываемой теме.

Хех, ну блин молодежь недоверчивая пошла, хорошо - более популярно. Что возникает при нарушении страничной защиты ? Правильно - прерывание которое Вы или Ваша OS должна обслужить. В теле интерцептора доступна вся информация об источнике его - и какую страничку подложить ограничено только вашей фантазией. В максимуме возможен вариант с 4Гб сегментов 8)

А адресок, если найду - запостю непременно - давно это было ....

> Зы - В догонку "Навороты" служат едиственной цели - увеличить обьем реальной физической памяти (>4GB) и снизить затраты на свопинг, но никоим раком
> они не относятся к обсасываемой теме.
Да понятное дело, тот же PAE просто сдвигает физический адрес, прописанный
в таблице страниц, на 4 разряда влево...
Только вот как с этим быть:
> там гдето валялась демонстрационная прожка распределявшая под досом 16 гиг виртуального адрессного
> пространсва.
Ведь это уже интересно.

> Хотя я не тот Анонимус, которому адресовалось это замечание, все же позволю с Вами не согласиться. На самом деле даже 32-х разрядная архитектура
> процессоров Intel позволяет адресовать значительно более 4 ГБ физической памяти (т.е. RАМ).
Блин, и как я сразу это не заметил... А ведь и вы мне про физическую
говорить начали, хотя я-то только о линейном пространстве говорил всё
время. Ну и нафига? :)

Блин - это был не я 8)

Я с самого начала говорил об виртуальном адрессном пространстве. И ни о чем более.

> Что возникает при нарушении страничной защиты ?
Секундочку, давайте быть последовательными:) Вы говорили "меняешь
базу и вперёд". Теперь уже обработчик PF вместо этого? Ну ладно,
проехали.

> В теле интерцептора доступна вся информация об источнике его
А какой источник то? Я хочу обратиться за 8Gb (заметьте, это с
вашей подачки я за 8 стал пытаться, хотя на самом деле по идее
если база+смещение выходит за 4Гб, то адрес просто врапается,
если мне память не изменяет). Так вот, как мне это сделать? Вы
предлагали DS:EBX. Если адрес и правда не врапается, то могу ещё
предположить ds:[ebx+esi] (что, кстати, даст 16 - это именно то,
о чём вы говорили?), но всему есть предел. Дальше уже не понятно
как крутиться... И ещё не понятно почему сегмент может не врапаться
если адрес 32-битный рассчитывается...

Хехехе Все правильно за одним исключением, обработчик (ну хотя бы в этом примере) был настроен так, что база отличающаяся хотя бы на 1 значила для него абсолютно новый 4гб кусок.

т.е. 0x000000 first 4 gb

0x000001 second 4 gb

ну и так далее

надеюсь дальше все понятно.

Т.е работая с парой ES:EBX и используя легальные 32 бит смещения Вы получаете возможность адрессовать виртуальную память свыше 4гиг меняя базу в ES

> предположить ds:[ebx+esi] (что, кстати, даст 16
Что-то я совсем заболтался. Если к 8 прибавить 4, вроде как 16 не
должно получиться, даже у меня:)

> Хехехе Все правильно за одним исключением, обработчик (ну хотя бы в этом примере) был настроен так, что база отличающаяся хотя бы на 1 значила для него
> абсолютно новый 4гб кусок.
Так я не понял, он вызывался-то в каком случае? Или он вызывается
вообще в любом случае, так как все страницы помечены как отсутствующие?

> надеюсь дальше все понятно.
Нет не понятно. Всё это звучит всё менее и менее правдоподобно.
Вызывать исключение при *любом* обращении к памяти - это ещё пол
беды. Дальше вас ждёт только 32 разряда адреса в cr2, и чтобы
получить полный адрес (ну тот, что ds:[ebx+esi]), нужно будет что,
декодировать инструкцию? А что потом? Помечать страницы как
присутствующие нельзя - в следующий раз не трапнется. Значит, эту
инструкцию придётся ещё и симулировать?
Нет, вы уж, пожалуйста, объясните один раз, но полностью. Хватит
ходить вокруг да около, я спать хочу, а не шарады разгадывать:)

> Т.е работая с парой ES:EBX и используя легальные 32 бит смещения Вы получаете возможность адрессовать виртуальную память свыше 4гиг меняя базу в ES
ОК, если смешения легальные, то вопросов меньше.
Но всё равно, в каком именно случае возникало исключение?
И как обработчик делал так, чтобы оно вызвалось снова как только
база изменится?
Не, покажите уж лучше пример, в самом деле...