IPC и обязательная верификация кода
От: Roman Odaisky Украина  
Дата: 29.06.09 11:08
Оценка: +1
Много думал, но не понял, как в ОС, исполняющих только верифицированный код, можно реализовать IPC, соблюдая изоляцию процессов.

Предположим, у нас есть ОС, представляющая собой Java-машину, умеющую исполнять только байткод Java. Вследствие того, что в Java строгая типизация, нет reinterpret_cast и прочих подобных хаков, каждый процесс получает указатели только из одного источника — из оператора new, соответственно, доступ в чужую память невозможен. Это снимает требование аппаратной защиты памяти и вообще звучит привлекательно. Вот только как реализовать IPC? Если у одного процесса есть большой кусок данных, и он хочет предоставить его другому для обработки, то он с помощью какого-нибудь системного вызова передает указатель, чтобы второй процесс смог получить доступ к данным. Однако что, если в том блоке есть указатели куда-то внутрь адресного пространства первого процесса? При отсутствии аппаратной защиты памяти второй процесс, нарушая принцип минимальных привилегий, сможет влезть куда не просят.

В традиционных системах эта задача решается тривиально, даже без копирования данных между процессами (разделяемая память, splice(2)/vmsplice(2) и т. д.). А вот как в ОС с защитой памяти, основанной на строгой типизации, можно передать объект из процесса в процесс (особенно без копирования) так, чтобы сохранить изоляцию процессов, — в общем случае, когда объект может содержать указатели на данные, которые передавать нельзя?

И еще, если на каждый байт памяти могут быть указатели из скольки угодно процессов, как это скажется на GC?
До последнего не верил в пирамиду Лебедева.
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.