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

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

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

И еще, если на каждый байт памяти могут быть указатели из скольки угодно процессов, как это скажется на GC?
До последнего не верил в пирамиду Лебедева.
Re: IPC и обязательная верификация кода
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 29.06.09 11:16
Оценка: +1
Здравствуйте, Roman Odaisky, Вы писали:

RO>Много думал, но не понял, как в ОС, исполняющих только верифицированный код, можно реализовать IPC, соблюдая изоляцию процессов.

Посмотри http://rsdn.ru/article/singularity/singularity.xml
Автор(ы): Galen Hunt, James Larus, Martin Abadi, Mark Aiken, Paul Barham, Manuel Fahndrich, Chris Hawblitzel, Orion Hodson, Steven Levi, Nick Murphy, Bjarne Steensgaard, David Tarditi, Ted Wobber, Brian Zill
Дата: 02.03.2006
Singularity – исследовательский проект Microsoft Research, который начался с вопроса: на что была бы похожа программная платформа, если спроектировать ее на пустом месте, и во главу угла поставить не производительность, а надежность?

Там есть Каналы, Exchange Heap
и солнце б утром не вставало, когда бы не было меня
Re: IPC и обязательная верификация кода
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 29.06.09 11:27
Оценка: +2 -1
Здравствуйте, Roman Odaisky, Вы писали:

RO>Много думал, но не понял, как в ОС, исполняющих только верифицированный код, можно реализовать IPC, соблюдая изоляцию процессов.


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


Проксировать доступ или передавать сериализованные копии.

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


GC должен быть общий для них. Сомневаюсь, что это есть где-то кроме AS/400.
The God is real, unless declared integer.
Re[2]: IPC и обязательная верификация кода
От: Roman Odaisky Украина  
Дата: 29.06.09 11:44
Оценка:
Здравствуйте, Serginio1, Вы писали:

S>Посмотри http://rsdn.ru/article/singularity/singularity.xml
Автор(ы): Galen Hunt, James Larus, Martin Abadi, Mark Aiken, Paul Barham, Manuel Fahndrich, Chris Hawblitzel, Orion Hodson, Steven Levi, Nick Murphy, Bjarne Steensgaard, David Tarditi, Ted Wobber, Brian Zill
Дата: 02.03.2006
Singularity – исследовательский проект Microsoft Research, который начался с вопроса: на что была бы похожа программная платформа, если спроектировать ее на пустом месте, и во главу угла поставить не производительность, а надежность?


«Инвариант Exchange Heap в том, что она не содержит никаких указателей на GC-кучу какого либо процесса. Таким образом, тип R должен быть обмениваемым типом, то есть примитивным value-типом (int, char и т.д.), перечислением или простой структурой с полями обмениваемых типов.»

Т. е., связный список передать уже не выйдет? (Хотя и в традиционных ОС это было бы затруднительно.)
До последнего не верил в пирамиду Лебедева.
Re[2]: IPC и обязательная верификация кода
От: Roman Odaisky Украина  
Дата: 29.06.09 11:44
Оценка: +1
Здравствуйте, netch80, Вы писали:

N>Проксировать доступ или передавать сериализованные копии.


А как можно обойтись без копирования?
До последнего не верил в пирамиду Лебедева.
Re: IPC и обязательная верификация кода
От: Mystic Украина http://mystic2000.newmail.ru
Дата: 29.06.09 12:13
Оценка:
Здравствуйте, Roman Odaisky, Вы писали:

RO>Много думал, но не понял, как в ОС, исполняющих только верифицированный код, можно реализовать IPC, соблюдая изоляцию процессов.


А просто файл создать в памяти нельзя? Или верифицированный код не может работать с файлами?
Re[3]: IPC и обязательная верификация кода
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 29.06.09 12:21
Оценка:
Здравствуйте, Roman Odaisky, Вы писали:

RO>Т. е., связный список передать уже не выйдет? (Хотя и в традиционных ОС это было бы затруднительно.)

Если только список на массиве.
и солнце б утром не вставало, когда бы не было меня
Re[3]: IPC и обязательная верификация кода
От: . Великобритания  
Дата: 29.06.09 12:32
Оценка: +1
Roman Odaisky wrote:

> А как можно обойтись без копирования?

Да как я понимаю, это теоретически невозможно. Жил-был у тебя граф объектный, раскиданный по всей памяти и вдруг выяснилось что его в другой процесс высылают. Нужно очень осторожно пройтись по ссылкам и выяснить что можно отдавать, а что нельзя, собрать в единый кусок и передать, либо каждому объекту приписывать токены, кому он виден, что скорее всего нехорошо скажется на производительности.
Posted via RSDN NNTP Server 2.1 beta
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[2]: IPC и обязательная верификация кода
От: Roman Odaisky Украина  
Дата: 29.06.09 12:41
Оценка:
Здравствуйте, Mystic, Вы писали:

RO>>Много думал, но не понял, как в ОС, исполняющих только верифицированный код, можно реализовать IPC, соблюдая изоляцию процессов.

M>А просто файл создать в памяти нельзя? Или верифицированный код не может работать с файлами?

Это явно лишнее копирование.

Например, ситуация: надо расшифровать полученные по сети данные, чем занимается отдельный процесс, имеющий доступ к ключам, но ни к чему более. В традиционных ОС можно отображать туда-сюда страницы памяти, на которых записаны данные, и без копирования перекидывать их между процессами, сохраняя безопасность остальных данных. Как что-либо подобное можно было бы сделать в «управляемых ОС»?
До последнего не верил в пирамиду Лебедева.
Re[3]: IPC и обязательная верификация кода
От: . Великобритания  
Дата: 29.06.09 12:48
Оценка:
Roman Odaisky wrote:

> Например, ситуация: надо расшифровать полученные по сети данные, чем

> занимается отдельный процесс, имеющий доступ к ключам, но ни к чему
> более. В традиционных ОС можно отображать туда-сюда страницы памяти, на
> которых записаны данные, и без копирования перекидывать их между
> процессами, сохраняя безопасность остальных данных. Как что-либо
> подобное можно было бы сделать в «управляемых ОС»?
Так тут просто — кидаться массивами byte.
Posted via RSDN NNTP Server 2.1 beta
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re: IPC и обязательная верификация кода
От: mkizub Литва http://symade.tigris.org
Дата: 29.06.09 12:51
Оценка: +2
Здравствуйте, Roman Odaisky, Вы писали:

RO>Много думал, но не понял, как в ОС, исполняющих только верифицированный код, можно реализовать IPC, соблюдая изоляцию процессов.


Тут и думать не надо. Проблемы нет как таковой, то есть она лишь в постановке задачи.
Если ОС следит за памятью и запуском GC, то у нас один GC на все процессы, и никаких проблем с передачей указателей нет.
Но если ты передал указатель в другой процесс — то у тебя уже нет изоляции процессов.
Если же ты не передаёшь указатели, а только данные — то изоляция есть. Копировать данные тоже нет нужды, так как их можно ложить в разделяемую область памяти, как и в обычном IPC. За содержимое разделяемой памяти отвечает единый GC единой ОС.
SOP & SymADE: http://symade.tigris.org , блог http://mkizub.livejournal.com
Re[4]: IPC и обязательная верификация кода
От: Roman Odaisky Украина  
Дата: 29.06.09 12:53
Оценка:
Здравствуйте, ., Вы писали:

.>Да как я понимаю, это теоретически невозможно.


Вот и меня это всё смущает. Получается какая-то очень полярная система: данные или видимы и к ним есть полный доступ, или вообще невидимы. Хотя... А если передавать, к примеру, const-объекты? Если код верифицирован, то обойти ограничения, накладываемые const, невозможно. Может, можно аналогичным образом реализовать систему прав доступа на уровне языка программирования? const же имеет нулевой оверхед, может, можно изобрести аналогичное языковое средство, и кастовать struct { int const x; int y; } * в struct { int const x; int invisible y; } * — что с этим может сделать злонамеренный код, не имея аналога const_cast? (Да, я знаю, что нельзя преобразовывать X** в X const**, но для Java-подобных языков, где указатели не перенацеливаются, это неактуально.)
До последнего не верил в пирамиду Лебедева.
Re[2]: IPC и обязательная верификация кода
От: Roman Odaisky Украина  
Дата: 29.06.09 12:55
Оценка:
Здравствуйте, mkizub, Вы писали:

M>Но если ты передал указатель в другой процесс — то у тебя уже нет изоляции процессов.

M>Если же ты не передаёшь указатели, а только данные — то изоляция есть.

Так а если надо передавать нечто сложнее byte[]? Связный список, например?

M>Копировать данные тоже нет нужды, так как их можно ложить в разделяемую область памяти, как и в обычном IPC.


А зачем разделяемая память в такой ОС, если можно выдать наружу указатель на любой кусок своей памяти?
До последнего не верил в пирамиду Лебедева.
Re[3]: IPC и обязательная верификация кода
От: mkizub Литва http://symade.tigris.org
Дата: 29.06.09 12:59
Оценка:
Здравствуйте, Roman Odaisky, Вы писали:

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


M>>Но если ты передал указатель в другой процесс — то у тебя уже нет изоляции процессов.

M>>Если же ты не передаёшь указатели, а только данные — то изоляция есть.

RO>Так а если надо передавать нечто сложнее byte[]? Связный список, например?


Нельзя передавать указатели на свою память, это нарушит изоляцию процессов. Указатели на разделяемую память — сколько угодно.

M>>Копировать данные тоже нет нужды, так как их можно ложить в разделяемую область памяти, как и в обычном IPC.


RO>А зачем разделяемая память в такой ОС, если можно выдать наружу указатель на любой кусок своей памяти?


Для изоляции процессов. Если она тебя не волнует — передавай без разделяемой памяти.
SOP & SymADE: http://symade.tigris.org , блог http://mkizub.livejournal.com
Re[3]: IPC и обязательная верификация кода
От: Mystic Украина http://mystic2000.newmail.ru
Дата: 29.06.09 13:06
Оценка: +1
Здравствуйте, Roman Odaisky, Вы писали:

RO>Это явно лишнее копирование.


RO>Например, ситуация: надо расшифровать полученные по сети данные, чем занимается отдельный процесс, имеющий доступ к ключам, но ни к чему более. В традиционных ОС можно отображать туда-сюда страницы памяти, на которых записаны данные, и без копирования перекидывать их между процессами, сохраняя безопасность остальных данных. Как что-либо подобное можно было бы сделать в «управляемых ОС»?


Ну создать в памяти файлик, куда бы возможность чтения/записи имели два процесса. Где лишнее копирование?

Ну а вообще любую память можно рассматривать как массив байт. Конечно, лишние проверки и необходимость хранить индексы вместо прямых указателей делает этот путь менее производительным и более геморройным в программировании, но позволяет показать эквивалентность между верифицированным кодом и обычным.
Re[4]: IPC и обязательная верификация кода
От: . Великобритания  
Дата: 29.06.09 13:30
Оценка:
Mystic wrote:

> Ну создать в памяти файлик, куда бы возможность чтения/записи имели два

> процесса. Где лишнее копирование?
Так это тривиально. Если заранее знать какие данные будут шариться, то их можно сразу делать как "тип R должен быть обмениваемым типом" и тогда пожалуйста. Но всё равно — копирование будет — данные пришли от пользователя как обычный String на куче, а его нужно поместить в тот самый файлик, либо в "тип R".
Posted via RSDN NNTP Server 2.1 beta
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[5]: IPC и обязательная верификация кода
От: . Великобритания  
Дата: 29.06.09 13:34
Оценка:
Roman Odaisky wrote:

> Вот и меня это всё смущает. Получается какая-то очень полярная система:

> данные или видимы и к ним есть полный доступ, или вообще невидимы.
> Хотя... А если передавать, к примеру, const-объекты? Если код
Может быть... в общем в сторону передачи строго RO-объектов стоит подумать. Получится erlang?

> верифицирован, то обойти ограничения, накладываемые const, невозможно.

> Может, можно аналогичным образом реализовать систему прав доступа на
> уровне языка программирования? const же имеет нулевой оверхед, может,
> можно изобрести аналогичное языковое средство, и кастовать struct { int
> const x; int y; } * в struct { int const x; int invisible y; } * — что с
> этим может сделать злонамеренный код, не имея аналога const_cast? (Да, я
> знаю, что нельзя преобразовывать X** в X const**, но для Java-подобных
> языков, где указатели не перенацеливаются, это неактуально.)
Что произойдёт со ссылками на другие объекты? struct {AnotherStructWithPassword const secretInfo;} ?
Posted via RSDN NNTP Server 2.1 beta
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[6]: IPC и обязательная верификация кода
От: Roman Odaisky Украина  
Дата: 29.06.09 14:12
Оценка:
Здравствуйте, ., Вы писали:

.>Что произойдёт со ссылками на другие объекты? struct {AnotherStructWithPassword const secretInfo;} ?


Так а если они не const, а invisible или что-нибудь вроде того?
До последнего не верил в пирамиду Лебедева.
Re[6]: IPC и обязательная верификация кода
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 29.06.09 14:21
Оценка:
Здравствуйте, ., Вы писали:

.>Может быть... в общем в сторону передачи строго RO-объектов стоит подумать. Получится erlang?


А кто за ними будет смотреть? GC только на процесс.

Главное решение в дизайне – инвариант независимости памяти: указатели между объектными пространствами указывают только на Exchange Heap. В частности, ядро не имеет указателей на объектное пространство процесса, и ни один процесс не имеет указателя на объекты другого процесса. Это гарантирует, что каждый процесс может подвергнуться сборке мусора и быть выгруженным без взаимодействия с другими процессами.



Exchange Heap отвечает в Singularity за эффективность коммуникаций, хранит данные, передаваемые между процессами (рисунок 2). Exchange Heap не подвергается сборке мусора, вместо этого используется подсчет ссылок для отслеживания использования блоков памяти, называемых регионами (regions). Процессы имеют доступ к региону через структуру allocation.

Структуры allocation также находятся в Exchange Heap, что позволяет передавать их между процессами, но каждая из них принадлежит в любой момент времени только одному процессу, который и может обращаться к ней. Нижележащий регион доступен только для чтения через несколько allocation. Кроме того, allocation могут иметь различную основу и границы, обеспечивающие различные представления нижележащих данных. Например, протокол, обрабатывающий код в сетевом стеке, может удалить из пакета инкапсулированные заголовки протокола, не копируя их. Регион отслеживает число allocation, указывающих на него, и освобождается, когда количество ссылок падает до нуля. Компилятор Singularity скрывает лишний уровень косвенности, предоставляя строго типизированную ссылку на регион и автоматически генерируя код, скрывающий подробности.

и солнце б утром не вставало, когда бы не было меня
Re[7]: IPC и обязательная верификация кода
От: Roman Odaisky Украина  
Дата: 29.06.09 14:33
Оценка:
Здравствуйте, Serginio1, Вы писали:

.>>Может быть... в общем в сторону передачи строго RO-объектов стоит подумать. Получится erlang? ;)

S>А кто за ними будет смотреть? GC только на процесс.

S>

S>Главное решение в дизайне – инвариант независимости памяти: указатели между объектными пространствами указывают только на Exchange Heap. В частности, ядро не имеет указателей на объектное пространство процесса, и ни один процесс не имеет указателя на объекты другого процесса. Это гарантирует, что каждый процесс может подвергнуться сборке мусора и быть выгруженным без взаимодействия с другими процессами.


Тогда zero copy не выйдет.
До последнего не верил в пирамиду Лебедева.
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.