Здравствуйте, ononim, Вы писали:

B>>так а можно сделать, чтобы клиентский код не мог писать в общий хип напрямую, а только вызывая апи сервиса? но мог читать, т.е. мог разыменовывать указатели из общего хипа
B>>тогда нужно будет лишь хорошо проверять входные параметры и всё
O>Не очень понял. Если имеется ввиду можно ли сделать хип read-only для непривелигированных процессов — то, конечно, можно. Более того, в винде такое юзается: user32 мапит кусочек session-space в readonly для всех процессов — там есть т.н. desktop и shared heap — они отображаются на юзермода как read-only страницы. Это позволяет обойтись без перехода в кернелмод для многих функций, не требующих изменения состояния, типа IsWindow, WindowFromPoint etc.

я имею ввиду иметь два сегмента юзеркода в одном процессе но у которых разные права на общий сегмент данных

т.е.
код сервиса находится в юзермоде в страницах из которых могут писать в общий сегмент данных
код клиента находится в юзермоде в страницах из которых НЕЛЬЗЯ прямо писать в общий сегмент данных, но можно вызывать код сервиса

такое реально? можно ли настроить разный доступ к одному сегменту с данными двум разным сегментам кода?
и всё — в юзер моде, потому что сервису нужны разные юзер апи

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 сделана — я хз. Когдато очень давно я писал свой велосипед с такой целью, но он проприетарен.

вы просто не всё поняли, идея была расшарить не только хип, но и код сервиса, чтобы дергать код сервиса из любого клиента напрямую по адресу.

все клиенты будут загружать сервисную длл

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

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

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

т.е. чтобы в итоге код сервисной длл мог возвращать указатели на с++ объекты в общем хипе
а клиенты могли читать эти указатели и делать вызовы этого кода, но не могли сами писать в общий хип

B>вы просто не всё поняли, идея была расшарить не только хип, но и код сервиса, чтобы дергать код сервиса из любого клиента напрямую по адресу.
B>сервисный код, ввиде длл, и так везде будет одинаковый, расшарить глобальные данные тоже не проблема через директивы компилятора
'Шаренье кода' в актуальных осях делается библиотеками, доменом безопасности является пользовательский акаунт, барьером — юзермод-кернелмод, доменом "надежности" — процесс, а юзермодное адресное пространство у каждого свое, надо исходить из этого. Это база, в которой вы работаете. В ней нельзя сделать магический код в юзермодном АП процесса, который будет обладать магическими привилегиями по сравнению с другим кодом в том же АП.
Если вас это не устраивает — нужна другая база, а ее нету, не считая экспериментов с софтварной безопасностью на основе верификации кода, типа, похороненной midori и еще гдето есть опенсурсная ось на такую тему, забыл ее название.

Здравствуйте, ononim, Вы писали:

B>>вы просто не всё поняли, идея была расшарить не только хип, но и код сервиса, чтобы дергать код сервиса из любого клиента напрямую по адресу.
B>>сервисный код, ввиде длл, и так везде будет одинаковый, расшарить глобальные данные тоже не проблема через директивы компилятора
O>'Шаренье кода' в актуальных осях делается библиотеками, доменом безопасности является пользовательский акаунт, барьером — юзермод-кернелмод, доменом "надежности" — процесс, а юзермодное адресное пространство у каждого свое, надо исходить из этого. Это база, в которой вы работаете. В ней нельзя сделать магический код в юзермодном АП процесса, который будет обладать магическими привилегиями по сравнению с другим кодом в том же АП.
O>Если вас это не устраивает — нужна другая база, а ее нету, не считая экспериментов с софтварной безопасностью на основе верификации кода, типа, похороненной midori и еще гдето есть опенсурсная ось на такую тему, забыл ее название.

ну вот это я и хотел узнать

ктса это всё даже не было бы проблемой в управляемой ОС, типа сингулярити, но она умерла не родившись

O>>Если вас это не устраивает — нужна другая база, а ее нету, не считая экспериментов с софтварной безопасностью на основе верификации кода, типа, похороненной midori и еще гдето есть опенсурсная ось на такую тему, забыл ее название.
B>ну вот это я и хотел узнать
B>ктса это всё даже не было бы проблемой в управляемой ОС, типа сингулярити, но она умерла не родившись
midori это и есть сингулярити в девичестве.

Здравствуйте, ononim, Вы писали:

O>>>Если вас это не устраивает — нужна другая база, а ее нету, не считая экспериментов с софтварной безопасностью на основе верификации кода, типа, похороненной midori и еще гдето есть опенсурсная ось на такую тему, забыл ее название.
B>>ну вот это я и хотел узнать
B>>ктса это всё даже не было бы проблемой в управляемой ОС, типа сингулярити, но она умерла не родившись
O>midori это и есть сингулярити в девичестве.

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

я просто смутно виртуальный режим х86 помню и что там можно а что нет

Здравствуйте, Barbar1an, Вы писали:

B>ктса это всё даже не было бы проблемой в управляемой ОС, типа сингулярити, но она умерла не родившись
Раз уж о таком заговорили — не проще ли взять управляемую среду, jvm какой-нибудь?