пятница, 14 мая 2010 г.

[prog] NativeClient от Google продолжает мутировать в интересном направлении

Google-воды явно понимают, что если все приложения для их Chromium OS будут писаться на JavaScript, то ничего хорошего из этого не выйдет. Поэтому они активно развивают NativeClient – инструмент для запуска нативного кода внутри браузера. Т.е. часть Web-приложения пишется на JavaScript, а часть – на C/C++. И нативная часть работает через NativeClient, что должно обеспечивать должную скорость и безопасность.

Если мне не изменяет мой склероз, первые версии NativeClient были очень ограничены по функциональности. Но со временем они стали позволять C/C++ программистам делать все больше и больше.

На днях Google выпустил очередную бета версию своего NativeClient SDK. Похоже, что NativeClient превращается в эдакий гипервизор для нативного кода. При полученном на тестах падении производительности в 3% обеспечивается высокий уровень безопасности: разработчикам доступен только ограниченный набор API-шных вызовов для взаимодействия с системой + к тому NativeClient контролирует выход за пределы отведенной нативному коду памяти.

Такими темпами из NativeClient может получиться практически виртуальная машина для C/C++. Особенно учитывая планы по подтягиванию к этому делу LLVM. Тогда вообще можно будет получить систему a la Java – С++ные приложения транслируются в LLVM-овский байт-код, который и передается на сторону клиента. Там он транслируется в нативный и исполняется с максимальной скоростью.

Опять же, если доверять моему склерозу, то Михаэль Франц, ученик Никлауса Вирта, когда-то критиковал Java за то, что там не было сделано именно так. Первые Java были интерпретаторами, HotSpot появился позднее. А Франц, помнится, тогда разработал для Компонентного Паскаля похожий подход – код транслировался в высокоуровневое бинарное представление, которое было кроссплатформенным. На конкретной платформе это представление специальными оптимизированными под платформу/архитектуру компиляторами транслировалось в машинный код. Причем вся эта кухня к моменту появления первых версий Java уже работала.

6 комментариев:

gp комментирует...

Есть какие-нибудь подробности по подключению к NaCl LLVM?

eao197 комментирует...

Гугл выдает вот эту ссылку: http://nativeclient.googlecode.com/svn/data/site/pnacl.pdf

Сам я никогда NaCl никогда вблизи не смотрел, просто читаю новости о нем.

Quaker комментирует...

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

Анонимный комментирует...

Женя, ты чуток народ вводишь в заблуждение. LLVM вообще не нужно было упоминать, да и Java тоже. NativeClient работает таким образом: бинарник (!!!) заливается по сети и проходит через очень маленький (по объему и функционалу) плагин браузера, который один раз проверяет бинарник на безопасность и отдает его на выполнение в процессор. Безопасность обеспечивается тем, что код проверки очень небольшой (код этого плагина браузера) в отличие от Явы. Кроме того, на код наложены жесткие ограничения: сегмент кода выполняется, но не пишется, данные пишутся, но не выполняются, команды косвенных переходов очень ограничены, команды выровнены по определенной границе (для гарантии дизассемблирования). Таким образом, в коде безопасности ошибки вычистят очень быстро (это не 30М ява машыны с библиотеками, это несколько килобайт плагина к браузеру) и этот код гарантирует, что то что он запустит после однократной проверки не сделает чего-нибудь неправильного. Выполняемый код работает на процессоре напрямую и общается только с API NativeClient.

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

Код для выоплнения генерит модифицированный GCC, который делает нужное выравнивание команд и не генерит разных косвенных переходов.

Подробности тут (на русском с картинками)

http://www.youtube.com/watch?v=Oknm3_82Pc0

Обсуждение тут

http://www.linux.org.ru/news/opensource/4884022

eao197 комментирует...

2san: в ответе на комментарий тов.gp я дал урл на PDF-ку, в которой показано, каким образом в NaCl используются наработки LLVM. Данная тобой ссылка на доклад датируется декабрем 2009, упомянутая мной PDF-ка февралем 2010. Думаю, за это время Google несколько пересмотрел свою технологию.

А за объяснение принципа работы NaCl спасибо.

eao197 комментирует...

Поправочка: даже не декабрем 2009, а ноябрем 2009.