B>я же хочу расшарить статические объекты и кучу, чтобы я мог обращаться к расшареным объектам как к обычному объекту, но с тем пониманием что он существует в одном экземпляре среди всех моих процессов
B>при этом чтобы когда я писал код главного процесса, я мог написать
B>auto d = new CObject ...
Здравствуйте, Barbar1an, Вы писали:
B>ну вообще я вкурсе как расшарить кусок данных, это не проблема
B>я же хочу расшарить статические объекты
Можно, и ты сам пишешь, что в курсе
>и кучу
А вот это AFAIK нет.
>чтобы я мог обращаться к расшареным объектам как к обычному объекту, но с тем пониманием что он существует в одном экземпляре среди всех моих процессов
file mapping, shared section в DLL.
B>при этом чтобы когда я писал код главного процесса, я мог написать
B>auto d = new CObject ...
Только если переопределить operator new так, чтобы он выделял память в расшаренной области.
B>и этот указатель становился сразу доступным всем дочерним процессам без спецаильных мер
Если все процессы укажут один и тот же желаемый адрес, и все эти запросы будут удовлетворены, то адрес будет один и тот же у всех процессов. Но нет никакой гарантии, что запросы всех процессов будут удовлетворены — в каком-то из процессов этот адрес может быть банально чем-то занят
Но вообще-то особой необходимости иметь эти адреса одинаковыми для всех процессов нет. Пусть каждый процесс маппит независимо, и базовые адреса будут различными. Если после этого каждый процесс будет оперировать не абсолютным адресом, а смещением от базового адреса, то все будет в порядке
Это не проблема, пусть только главный создает мэппинг R/W, а дочерние R/O
B>типа сделать глобальный пул, в нём порождать всё не перебирая, что нужно а что нет — это удобство B>этот пул замапить во все дочерние процесс как read-only
Да, примерно так и будет
B>тогда можно было бы дергать в дочерних процессах указатели на данные в этом пуле напрямую, и не бояться похерить их
Можно
B>но это реально тока если адреса маппинга страниц памяти во всех процессах будут одинаковые — можно ли такое? иначе ничего не получится, потому что указатели же ж это абсолютные значения в виртуальном пространстве адресов
Как уже писали, главная проблема — получить фиксированный между разными процессами адрес, чтоб не занят был. В принципе если говорить про драйвер, то это несложно сделать из нотификации на создание процесса резервировать регион памяти по заданному адресу и радоваться жизни. Вопрос какой адрес выбрать для фиксации, а выбрать надо такой, чтоб не перекрывался с адресом загрузки базовых длл (ntdll/kernelbase/kernel32/user32/gdi32/может-там-еще-чего-добавили) в данной сессии и не перекрывался с адресом загрузки ваших ехе модулей.
Предполагаемый функционал в драйвере:
— Драйвер имеет admin-only IOCTL, который ему говорит: для процессов, созданных из имажа с таким то путем резервируй адреса с такогото по такой-то.
Предполагаемый функционал в юзермодном 'главном' сервисе:
— При запуске определяет текущие ASLR-ed базы указанных выше длл, ехе-шника нужного имажа/ов, подбирает заданный адрес и дергает драйвер за тот самый IOCTL.
— Имеет локальный IPC, через пайпы например или LPC, который позволяет дернуть его из непривелигированного процесса, запросив shared memory. При дерганье сервис создает персональнй mapping, занимающий некоторый заданный диапазон адресов зарезервированного пула между собой и процессом клиентом. MapViewOfFile2 позволяет промапить неименованный анонимный мапинг в АП чужого процесса. Ну или NtMapViewOfSection, если вы без комплексов.
— При желании на эту область памяти можно даже натянуть хип.
— Помимо мапинга вам еще понадобится некая синхронизация клиент-сервер.
Очевидные недостатки — область памяти будет иметь захардкоженный размер на всех и еще меньший размер на одного клиента. В принципе, на х64 этот размер может быть достаточно велик для любых применений, главное — не комтить страницы сразу, а максимально пользоваться MEM_RESERVE/SEC_RESERVE.
В итоге получится не требующий фиксапов межпроцессный хип.
Скрытый текст
Но это все равно глупая затея. И дело не в трудоемкости. Защищенность сервиса предполагает, что клиент не сможет его порушить. А значит, что сервису придется тщательно смотреть за структурами данных, которые ему в расшаренную память положил процесс. Причем это значит, что клиент, будучи написанным хакером, может abuse-ить ваш протокол, к примеру записывая в расшаренную память в обход предусмотренного механизма синхронизации. Это не то чтобы нерешаемая задача — можно обеспечить транзакционную синхронизацию, переключающую режим работы хипа между клиентом и сервисов устанавливая защиту на страницы памяти которую клиент не сможет изменить, но по итогу с такой синхронизацией + проверками валидности данных работать оно врядл будет быстрее чем реализация протокола-через-пайпы. А без них — ни о какой защищенности кода говорить нельзя и проще заюзать предложенный выше буст.
Как много веселых ребят, и все делают велосипед...
есть проект в котором есть один главный процесс и куча дочерних
они ессно меж собой должны взаимодействовать, причем активно гоняя кучу данных
при этом дочерние процессы не должны иметь никакой возможности убить главный
классически это делается через сериализацию
но меня смущает что нужно по сути городить сетевой протокол там де он и не нужен, и будет создавать кучу накладных расходов
а нельзя ли както сделать так чтобы код, который общий, был в расшареном сегменте, т.е. был замаплен во все дочерние процессы и был при этом доступен для них только на вызов
чтобы дочерний процесс не мог покоцать ни расшареный код, ни его данные
и чтобы можно было общаться с ним через с/с++ интерфейсы например, т.е. без всех этих 0-to-3 ring переходов
может user-mode драйвера както тут помогут? не знаю пока что они могут, но расшаренный код должен иметь все возможности обычного user-mode режима
было бы очень странно если бы такой возможности не было, потому как сериализовать/ждать/десериализовывать там де нужен простой потокобезопасный вызов кажется мне большой печалью и геморроем
Я изъездил эту страну вдоль и поперек, общался с умнейшими людьми и я могу вам ручаться в том, что обработка данных является лишь причудой, мода на которую продержится не более года. (с) Эксперт, авторитет и профессионал из 1957 г.
Здравствуйте, Barbar1an, Вы писали:
B>... B>а нельзя ли както сделать так чтобы код, который общий, был в расшареном сегменте, т.е. был замаплен во все дочерние процессы и был при этом доступен для них только на вызов B>чтобы дочерний процесс не мог покоцать ни расшареный код, ни его данные B>и чтобы можно было общаться с ним через с/с++ интерфейсы например, т.е. без всех этих 0-to-3 ring переходов
B>может user-mode драйвера както тут помогут? не знаю пока что они могут, но расшаренный код должен иметь все возможности обычного user-mode режима
Если строго под Windows, я бы, наверное, использовал Microsoft RPC.
Если вкратце: это дешево и сердито, зато достаточно быстро (накладные расходы очень незначительные) и
безопасно (со стороны клиента уронить или подвесить сервер практически нереально, только разве что
через какую-нибудь уязвимость в системе).
Сначала в IDL-файле описываются все нужные интерфейсы, потом файл компилируется MIDL-компилятором и
сгенерированные файлы .c и .h подключаются к соответствующим проектам. Далее нужно написать код
инициализации клиента и сервера — это, условно говоря, пара страниц кода.
После этого вызовы функций интерфейса будут "прозрачно" превращаться в удаленные, причем клиент и
сервер могут быть как в пределах одной машины, так и на разных. В случае использования в доменных
средах доступны все соответствующие "фишки" AD: доменная аутентификация, kerberos и т.п.
Еще быстрее, наверное, (A)LPC, — ее использует Windows для обмена информацией между процессами, —
но эта технология, в отличие от MS RPC, почти полностью недокументированная.
Здравствуйте, Barbar1an, Вы писали:
B>есть проект в котором есть один главный процесс и куча дочерних B>они ессно меж собой должны взаимодействовать, причем активно гоняя кучу данных B>при этом дочерние процессы не должны иметь никакой возможности убить главный
B>классически это делается через сериализацию
Здравствуйте, Barbar1an, Вы писали:
B>а нельзя ли както сделать так чтобы код, который общий, был в расшареном сегменте, т.е. был замаплен во все дочерние процессы и был при этом доступен для них только на вызов
Можно, путем вынесения этого кода в DLL
B>чтобы дочерний процесс не мог покоцать ни расшареный код, ни его данные
Насчет данных сложнее. Процесс может создать memory mapped file, и передать другому процессу HANDLE с правами "только на чтение", а другой процесс, соответственно, замапирует его к себе, без права записи.
Я на вскидку не помню уже вендовый API на эту тему, вроде можно создать и анонимный "memory mapping", без дискового файла, стоящего за ним.
B>и чтобы можно было общаться с ним через с/с++ интерфейсы например, т.е. без всех этих 0-to-3 ring переходов
Если один процесс ждет чего-то от другого, то в тот момент, когда другой ему это предоставил, чтобы разбудить ждущий процесс, все равно придется пройти через ядро.
B>было бы очень странно если бы такой возможности не было, потому как сериализовать/ждать/десериализовывать там де нужен простой потокобезопасный вызов кажется мне большой печалью и геморроем
Вендовый RPC, я слышал, использует для этих целей недокументированный API, который умеет пересылать сообщения между процессами, путем перемапливания страниц памяти из адресного пространства одной задачи в другую.
Не факт, что это так уж и бесплатно, потому что каждое такое перемапливание сбрасывает TLB
ну вообще я вкурсе как расшарить кусок данных, это не проблема
я же хочу расшарить статические объекты и кучу, чтобы я мог обращаться к расшареным объектам как к обычному объекту, но с тем пониманием что он существует в одном экземпляре среди всех моих процессов
при этом чтобы когда я писал код главного процесса, я мог написать
auto d = new CObject ...
и этот указатель становился сразу доступным всем дочерним процессам без спецаильных мер
типа например вот так, auto d = new CObject( ..., global_allocator)
но при этом дочерние процессы не должны иметь возможности покоцать эти общедоступные объекты
типа сделать глобальный пул, в нём порождать всё не перебирая, что нужно а что нет — это удобство
этот пул замапить во все дочерние процесс как read-only
тогда можно было бы дергать в дочерних процессах указатели на данные в этом пуле напрямую, и не бояться похерить их
но это реально тока если адреса маппинга страниц памяти во всех процессах будут одинаковые — можно ли такое? иначе ничего не получится, потому что указатели же ж это абсолютные значения в виртуальном пространстве адресов
Я изъездил эту страну вдоль и поперек, общался с умнейшими людьми и я могу вам ручаться в том, что обработка данных является лишь причудой, мода на которую продержится не более года. (с) Эксперт, авторитет и профессионал из 1957 г.
Здравствуйте, Barbar1an, Вы писали:
B>этот пул замапить во все дочерние процесс как read-only
т.е. страницы с общим кодом(DLL) должны иметь возможность писать в этот пул, а приватные страницы кода дочерних процессов — не должны
тогда я не смогу прямо покоцать общий пул, но вызвала код DLL смогу менять данные
это вообще реально в венде?
наверно это нереал, вроде как права на то куда можно, а куда — нет, нельзя устанавливать для отдельных сегментов кода
Я изъездил эту страну вдоль и поперек, общался с умнейшими людьми и я могу вам ручаться в том, что обработка данных является лишь причудой, мода на которую продержится не более года. (с) Эксперт, авторитет и профессионал из 1957 г.
Здравствуйте, Barbar1an, Вы писали:
B>но это реально тока если адреса маппинга страниц памяти во всех процессах будут одинаковые — можно ли такое? иначе ничего не получится, потому что указатели же ж это абсолютные значения в виртуальном пространстве адресов
Можно вместо указателей использовать смещения от начала этого глобального пула.
Теоретически, при создании маппинга можно указать адрес. Но практически надо очень хорошо понимать, как устроена вся эта внутренняя кухня, чтобы этот диапазон адресного пространства не оказался вдруг неожиданно занят.
PD>Но вообще-то особой необходимости иметь эти адреса одинаковыми для всех процессов нет. Пусть каждый процесс маппит независимо, и базовые адреса будут различными. Если после этого каждый процесс будет оперировать не абсолютным адресом, а смещением от базового адреса, то все будет в порядке
ну это ж неудобно нифига, придется везде добавлять смещение и делать кучу конверсий, к каждому указателю коих сотни будут
Я изъездил эту страну вдоль и поперек, общался с умнейшими людьми и я могу вам ручаться в том, что обработка данных является лишь причудой, мода на которую продержится не более года. (с) Эксперт, авторитет и профессионал из 1957 г.
Здравствуйте, Pavel Dvorkin, Вы писали:
B>>auto d = new CObject ...
PD>Только если переопределить operator new так, чтобы он выделял память в расшаренной области.
тут вот проблема что для своих объектов я могу переопределить new, а если я например возвращаю референс на std::string? и вообще все std классы где будут инициироваться сами и свои потроха? а де попало...
или там всё так круто написано что мой аллокатор и все потроха разместит в том пуле который мне нужен?
но всё равно куча рисков сохраняется например
class A
{
std::string Text;
A * operanor new (...
}
autp a = new A
запихнет Text туда же куда и A
а потроха Text, (буфер текста) будут в каком пуле?
может проще вообще все XxxxAlloc перехватить и перенаправить на общий пул?
Я изъездил эту страну вдоль и поперек, общался с умнейшими людьми и я могу вам ручаться в том, что обработка данных является лишь причудой, мода на которую продержится не более года. (с) Эксперт, авторитет и профессионал из 1957 г.
или мож в стд есть способ глобально сменить пул по умолчанию?
а если такое есть...как тогда глобальные переменные стд? они ж инициализируются до передачи управления в main , или они дефолтный пул не используют?
Я изъездил эту страну вдоль и поперек, общался с умнейшими людьми и я могу вам ручаться в том, что обработка данных является лишь причудой, мода на которую продержится не более года. (с) Эксперт, авторитет и профессионал из 1957 г.
Отвечаю на все 3 здесь
B>ну это ж неудобно нифига, придется везде добавлять смещение и делать кучу конверсий, к каждому указателю коих сотни будут
Неудобно, конечно, но можно функцию соорудить
>тут вот проблема что для своих объектов я могу переопределить new, а если я например возвращаю референс на std::string? и вообще все std классы где будут инициироваться сами и свои потроха? а де попало...
Ну вообще-то у классов STD есть возможность свой аллокатор использовать.
B>а если такое есть...как тогда глобальные переменные стд? они ж инициализируются до передачи управления в main , или они дефолтный пул не используют?
Боюсь, что ты хочешь невозможного.
Кучи процессов не шарятся, они per process. Поэтому если использовать RTL кучу, то ничего не выйдет. Свои объекты, память для которых ты выделяешь сам по mmf механизму, шарить можно.
странно что вообще эта тема нигде не проработана, нет инстументария
а file mapping — это очень мало
а ведь она сильно бы упростила написание устойчивых машстабируемых систем
ибо я не вижу особых проблем дергать такие, глобальные, указатели в разных процессах, добавь потокобезопасность и всё, никаких проблем
и не нужен весь этот геморрой с сериализацией, идентификацией объектов и прочим, скока процессорного времени тратится на этот мусор! единственная польза — что можно по сети всё это гонять
Я изъездил эту страну вдоль и поперек, общался с умнейшими людьми и я могу вам ручаться в том, что обработка данных является лишь причудой, мода на которую продержится не более года. (с) Эксперт, авторитет и профессионал из 1957 г.
Здравствуйте, Barbar1an, Вы писали:
B>странно что вообще эта тема нигде не проработана, нет инстументария
Был. Причем был совершенно всем доступный. Это был механизм управления памятью в 16-битной Windows. Там куча (глобальная) была одна для всех задач (так тогда называли процессы). Можно было выделить память в одной задаче и передать указатель в другую. И даже освободить память в другой можно было.
А вот в Win32 все же у каждого процесса свое адресное пространство, поэтому доступ к общей памяти требует усилий. Он не тривиален — если не синхронизировать, то будет плохо. Да и вообще идея получить указатель в одном процессе и передать его в другой не очень соответствует современным принципам. Тут много проблем, и их в Win API и C++ CRT не решают, а только предоставляют средства, на базе которых каждый может попробовать свое написать — на свой страх и риск.
Здравствуйте, ononim, Вы писали:
O>Но это все равно глупая затея. И дело не в трудоемкости. Защищенность сервиса предполагает, что клиент не сможет его порушить. А значит, что сервису придется тщательно смотреть за структурами данных, которые ему в расшаренную память положил процесс. Причем это значит, что клиент, будучи написанным хакером, может abuse-ить ваш протокол, к примеру записывая в расшаренную память в обход предусмотренного механизма синхронизации. Это не то чтобы нерешаемая задача — можно обеспечить транзакционную синхронизацию, переключающую режим работы хипа между клиентом и сервисов устанавливая защиту на страницы памяти которую клиент не сможет изменить, но по итогу с такой синхронизацией + проверками валидности данных работать оно врядл будет быстрее чем реализация протокола-через-пайпы. А без них — ни о какой защищенности кода говорить нельзя и проще заюзать предложенный выше буст.
так а можно сделать, чтобы клиентский код не мог писать в общий хип напрямую, а только вызывая апи сервиса? но мог читать, т.е. мог разыменовывать указатели из общего хипа
тогда нужно будет лишь хорошо проверять входные параметры и всё
Я изъездил эту страну вдоль и поперек, общался с умнейшими людьми и я могу вам ручаться в том, что обработка данных является лишь причудой, мода на которую продержится не более года. (с) Эксперт, авторитет и профессионал из 1957 г.
B>так а можно сделать, чтобы клиентский код не мог писать в общий хип напрямую, а только вызывая апи сервиса? но мог читать, т.е. мог разыменовывать указатели из общего хипа B>тогда нужно будет лишь хорошо проверять входные параметры и всё
Не очень понял. Если имеется ввиду можно ли сделать хип read-only для непривелигированных процессов — то, конечно, можно. Более того, в винде такое юзается: user32 мапит кусочек session-space в readonly для всех процессов — там есть т.н. desktop и shared heap — они отображаются на юзермода как read-only страницы. Это позволяет обойтись без перехода в кернелмод для многих функций, не требующих изменения состояния, типа IsWindow, WindowFromPoint etc.
Как много веселых ребят, и все делают велосипед...
Здравствуйте, ononim, Вы писали:
B>>так а можно сделать, чтобы клиентский код не мог писать в общий хип напрямую, а только вызывая апи сервиса? но мог читать, т.е. мог разыменовывать указатели из общего хипа B>>тогда нужно будет лишь хорошо проверять входные параметры и всё O>Не очень понял. Если имеется ввиду можно ли сделать хип read-only для непривелигированных процессов — то, конечно, можно. Более того, в винде такое юзается: user32 мапит кусочек session-space в readonly для всех процессов — там есть т.н. desktop и shared heap — они отображаются на юзермода как read-only страницы. Это позволяет обойтись без перехода в кернелмод для многих функций, не требующих изменения состояния, типа IsWindow, WindowFromPoint etc.
я имею ввиду иметь два сегмента юзеркода в одном процессе но у которых разные права на общий сегмент данных
т.е.
код сервиса находится в юзермоде в страницах из которых могут писать в общий сегмент данных
код клиента находится в юзермоде в страницах из которых НЕЛЬЗЯ прямо писать в общий сегмент данных, но можно вызывать код сервиса
такое реально? можно ли настроить разный доступ к одному сегменту с данными двум разным сегментам кода?
и всё — в юзер моде, потому что сервису нужны разные юзер апи
Я изъездил эту страну вдоль и поперек, общался с умнейшими людьми и я могу вам ручаться в том, что обработка данных является лишь причудой, мода на которую продержится не более года. (с) Эксперт, авторитет и профессионал из 1957 г.
B>я имею ввиду иметь два сегмента юзеркода в одном процессе но у которых разные права на общий сегмент данных B>т.е. B>код сервиса находится в юзермоде в страницах из которых могут писать в общий сегмент данных B>код клиента находится в юзермоде в страницах из которых НЕЛЬЗЯ прямо писать в общий сегмент данных, но можно вызывать код сервиса B>такое реально? можно ли настроить разный доступ к одному сегменту с данными двум разным сегментам кода? B>и всё — в юзер моде, потому что сервису нужны разные юзер апи
У вас некоторая каша в голове. Но ответ — реально. Код клиента — это процесс клиента, код сервиса — это процесс сервиса.
То что вы хотите реализовывается по тому же сценарию что я описал в первой мессаге, с некоторыми дополнениями
1) Сервис мапит файлампинг клиенту с PageProtection = PAGE_READONLY.
2) Синхронизация все равно потребуется, но без подвыподвертов, связанных с безопасностью. Кстати, чтобы достить максимума производительности можно сделать аналог критической секции на расшаренной памяти, что означает что помимо READ/WRITE области памяти потребуется еще одна маленькая область, writable для клиента, чтобы тот мог реализовать на ней вспомогательный спинлок. Обычную CRITICAL_SECTION так заюзать нельзя. Будет ли буст оптимален для такого сценария или у них межпроцессная синхронизация тупо на CreateMutex/WaitForSingleObject сделана — я хз. Когдато очень давно я писал свой велосипед с такой целью, но он проприетарен.
Как много веселых ребят, и все делают велосипед...
Здравствуйте, ononim, Вы писали:
O>У вас некоторая каша в голове. Но ответ — реально. Код клиента — это процесс клиента, код сервиса — это процесс сервиса. O>То что вы хотите реализовывается по тому же сценарию что я описал в первой мессаге, с некоторыми дополнениями O>1) Сервис мапит файлампинг клиенту с PageProtection = PAGE_READONLY. O>2) Синхронизация все равно потребуется, но без подвыподвертов, связанных с безопасностью. Кстати, чтобы достить максимума производительности можно сделать аналог критической секции на расшаренной памяти, что означает что помимо READ/WRITE области памяти потребуется еще одна маленькая область, writable для клиента, чтобы тот мог реализовать на ней. Обычную CRITICAL_SECTION так заюзать нельзя. Будет ли буст оптимален для такого сценария или у них межпроцессная синхронизация тупо на CreateMutex/WaitForSingleObject сделана — я хз. Когдато очень давно я писал свой велосипед с такой целью, но он проприетарен.
вы просто не всё поняли, идея была расшарить не только хип, но и код сервиса, чтобы дергать код сервиса из любого клиента напрямую по адресу.
все клиенты будут загружать сервисную длл
сервисный код, ввиде этой длл, и так везде будет одинаковый, расшарить глобальные данные тоже не проблема через директивы компилятора
проблема была сделать такой расшареный хип чтобы код сервисной длл, который присутсвует во всех клиенских процессах, мог в него писать
а код клиентов, которому мы не доверяем, не мог писать в общий хип, но мог вызывать прямо код сервисной длл, которая, еще раз, присутсвует во всех клиенских процессах
т.е. сервисная длл тут выступает в том числе как прокси, который ограничивает клиентов в праве на прямую запись в общий хип, зато разрешает делать это через предоставляемый апи
т.е. чтобы в итоге код сервисной длл мог возвращать указатели на с++ объекты в общем хипе
а клиенты могли читать эти указатели и делать вызовы этого кода, но не могли сами писать в общий хип
Я изъездил эту страну вдоль и поперек, общался с умнейшими людьми и я могу вам ручаться в том, что обработка данных является лишь причудой, мода на которую продержится не более года. (с) Эксперт, авторитет и профессионал из 1957 г.
B>вы просто не всё поняли, идея была расшарить не только хип, но и код сервиса, чтобы дергать код сервиса из любого клиента напрямую по адресу. B>сервисный код, ввиде длл, и так везде будет одинаковый, расшарить глобальные данные тоже не проблема через директивы компилятора
'Шаренье кода' в актуальных осях делается библиотеками, доменом безопасности является пользовательский акаунт, барьером — юзермод-кернелмод, доменом "надежности" — процесс, а юзермодное адресное пространство у каждого свое, надо исходить из этого. Это база, в которой вы работаете. В ней нельзя сделать магический код в юзермодном АП процесса, который будет обладать магическими привилегиями по сравнению с другим кодом в том же АП.
Если вас это не устраивает — нужна другая база, а ее нету, не считая экспериментов с софтварной безопасностью на основе верификации кода, типа, похороненной midori и еще гдето есть опенсурсная ось на такую тему, забыл ее название.
Как много веселых ребят, и все делают велосипед...
Здравствуйте, ononim, Вы писали:
B>>вы просто не всё поняли, идея была расшарить не только хип, но и код сервиса, чтобы дергать код сервиса из любого клиента напрямую по адресу. B>>сервисный код, ввиде длл, и так везде будет одинаковый, расшарить глобальные данные тоже не проблема через директивы компилятора O>'Шаренье кода' в актуальных осях делается библиотеками, доменом безопасности является пользовательский акаунт, барьером — юзермод-кернелмод, доменом "надежности" — процесс, а юзермодное адресное пространство у каждого свое, надо исходить из этого. Это база, в которой вы работаете. В ней нельзя сделать магический код в юзермодном АП процесса, который будет обладать магическими привилегиями по сравнению с другим кодом в том же АП. O>Если вас это не устраивает — нужна другая база, а ее нету, не считая экспериментов с софтварной безопасностью на основе верификации кода, типа, похороненной midori и еще гдето есть опенсурсная ось на такую тему, забыл ее название.
ну вот это я и хотел узнать
ктса это всё даже не было бы проблемой в управляемой ОС, типа сингулярити, но она умерла не родившись
Я изъездил эту страну вдоль и поперек, общался с умнейшими людьми и я могу вам ручаться в том, что обработка данных является лишь причудой, мода на которую продержится не более года. (с) Эксперт, авторитет и профессионал из 1957 г.
O>>Если вас это не устраивает — нужна другая база, а ее нету, не считая экспериментов с софтварной безопасностью на основе верификации кода, типа, похороненной midori и еще гдето есть опенсурсная ось на такую тему, забыл ее название. B>ну вот это я и хотел узнать B>ктса это всё даже не было бы проблемой в управляемой ОС, типа сингулярити, но она умерла не родившись
midori это и есть сингулярити в девичестве.
Как много веселых ребят, и все делают велосипед...
Здравствуйте, ononim, Вы писали:
O>>>Если вас это не устраивает — нужна другая база, а ее нету, не считая экспериментов с софтварной безопасностью на основе верификации кода, типа, похороненной midori и еще гдето есть опенсурсная ось на такую тему, забыл ее название. B>>ну вот это я и хотел узнать B>>ктса это всё даже не было бы проблемой в управляемой ОС, типа сингулярити, но она умерла не родившись O>midori это и есть сингулярити в девичестве.
я уже понял почему это изначльно нереал был, это значило бы что на каждую страницу памяти нужно иметь дескриптор безопасности и загружать их при каждом обращении за пределы текущей страницы
что убило бы общий пефоманс напрочь
я просто смутно виртуальный режим х86 помню и что там можно а что нет
Я изъездил эту страну вдоль и поперек, общался с умнейшими людьми и я могу вам ручаться в том, что обработка данных является лишь причудой, мода на которую продержится не более года. (с) Эксперт, авторитет и профессионал из 1957 г.
Здравствуйте, Barbar1an, Вы писали:
B>ктса это всё даже не было бы проблемой в управляемой ОС, типа сингулярити, но она умерла не родившись
Раз уж о таком заговорили — не проще ли взять управляемую среду, jvm какой-нибудь?
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
