Поведение и системные вызовы NaCl sel_ldr

Question

В SDK разработчика NaCl (родной клиент) есть sel_ldr.py (безопасный загрузчик эльфа), который позволяет пользователю запускать исполняемый файл NaCl (.nexe), созданный с помощью инструментальной цепочки NaCl или PNaCl. Что именно делает sel_ldr.py во время работы этих .nexe файлов?

В частности, как sel_ldr обрабатывает вызовы операционной системы исполняемых файлов NaCl? Чтение документации NaCl. Большая часть информации относится к использованию API перечня для создания переносимых приложений браузера Chrome, и нет подробных сведений о том, как sel_ldr service-runtime обрабатывает эти исполняемые файлы NaCl.

Я создал много исполняемых файлов NaCl, которые во время работы в sel_ldr могут создавать каталоги, файлы, каналы, выполнять спящий режим и использовать различные другие системные вызовы, и он работает правильно. Я знаю, что собственный клиент сам контролирует системные вызовы. Этот мониторинг выполняется с использованием API-интерфейса перечня или sel_ldr.py перехватывает и перенаправляет системные вызовы на собственные решения системного вызова NaCl в своей изолированной программной среде?

Answer 1

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

Pepper API-вызовы - это еще один тип системного вызова, но они присутствуют только в Chrome. Перфектные вызовы в действительности представляют собой межпроцессную связь между модулем NaCl и процессами Chrome.

Общая реализация - время выполнения службы, хорошее описание можно найти в original NaCl research paper. Есть более старый сайт (к сожалению, не текущая документация) с anatomy of a syscall, и источник явно открыт.