|
| NaCl или "В чём соль?"16 май 2010 00:59 | |
Для тех, кто ещё не в курсе:
"Компания Google выпустила предварительную версию SDK для упрощения разработки полноценных web-приложений, функционирующих в среде Native Client, позволяющей выполнять в окне web-браузера обычные бинарные программы, ограниченные в специальном изолированном окружении. Изначально Native Client был создан для адаптации существующих программ для работы в браузере, но теперь продвигается и как платформа для создания универсальных web-приложений, написанных на языке C/C++ и использующих для выполнения свойственных web-приложениям действий специальный API." - и так далее, читать тут:
http://opennet.ru/opennews/art.shtml?num=26593
Вкратце: это значит, что в веб-страницу можно встроить бинарник, скомпилированный из C/C++ кода, и у него будет и быстродействие "родных" приложений и кроссплатформенность и это будет безопасно.
Новый виток гонки технологий? А что думаете вы? Стоит ли отбрасывать flash, silverlight и unity3d и браться за javascript и C/C++?
|
|
Отправлено 16.05.2010 в 09:53
|
 |
Павел Окопный пишет:
>
> Вкратце: это значит, что в веб-страницу можно
> встроить бинарник, скомпилированный из C/C++ кода,
> и у него будет и быстродействие "родных"
> приложений и кроссплатформенность и это будет
> безопасно.
Это они всех к Chromium готовят.
> Новый виток гонки технологий? А что думаете вы?
> Стоит ли отбрасывать flash, silverlight и unity3d
> и браться за javascript и C/C++?
Все там будем :)
ЗЫ: Кнопки "комментировать" местами что ли поменяли? В личку сообщение случайно ушло.
|
|
Отправлено 16.05.2010 в 13:09
|
|
ActiveX 2.0 :)
Фактически, ничего нового в этой технологии нет. Вопрос в том что будут давать в плане пайплайна и как они обеспечат install base.
Flash, Silverlight, Unity3D - это не столько возможность выполнить код в браузере, сколько - уникальные пайплайны.
|
|
Отправлено 16.05.2010 в 13:19
|
|
Андрей Олейник пишет:
>
> ActiveX 2.0 :)
> Фактически, ничего нового в этой технологии нет.
> Вопрос в том что будут давать в плане пайплайна и как
> они обеспечат install base.
Вот мне тоже это интересно. Буду следить за темой.
Честно говоря, я думаю, всё будет достаточно продумано.
|
|
Отправлено 16.05.2010 в 13:24
|
|
А каким образом эти приложения изолируются, чтобы они не могли нанести вред системе?
|
|
Отправлено 16.05.2010 в 13:36
|
|
Антон Шеховцов пишет:
>
> А каким образом эти приложения изолируются, чтобы они
> не могли нанести вред системе?
В статье все описано. Путём ограничения и подмены системных вызовов. Фактически там низкоуровневая виртуальная машина.
|
|
Отправлено 16.05.2010 в 13:38
|
|
Первое, что приходит в голову - запуск только подписанных приложений.
|
|
Отправлено 16.05.2010 в 15:10
|
|
У меня чуть-чуть устаревшие данные, но суть вряд ли поменялась:
Перед запуском особый джедайский верификатор быстро (порядка 30 мб/с) проверяет приложение на наличие недопустимых ассемблерных инструкций, рвущихся наружу.
Чтобы было неповадно обфусцировать дизассемблер (эксплойтя тот факт, что инструкции под x86 имеют переменную длину, и вполне можно упрятать одну внутрь другой со смещением), call/jmp разрешаются только по адресам кратностью 32 байта, и ни одна инструкция не может приходиться на стык двух 32-байтных блоков (т.е. гарантируется, что можно дизассемблировать весь код блоками по 32 байта). Прыгать можно только в начала этих блоков.
Для обеспечения выравнивания в конце каждого блока добиваются nop’ы. Ну и просто если в коде каскад маленьких if’ов, начала их блоков, кроме первого, тоже нужно выравнивать. Говорят, средний код раздувается на ~10-15%.
Любой jmp/call/ret по не-фиксированному адресу верифицироваться не может, а потому перед каждым таким jmp/call/ret требуется наличие строго фиксированного кода, затирающего младшие 5 бит (это необходимое условие прохождения верификатора). Среднее приложение теряет здесь 2-5% производительности. Вроде бы раньше ещё собирались старшие биты адресов обрезать, но чем тут закончилось обсуждение, мне не известно.
Подписывать приложение не требуется. Предоставляется модификация GCC, которая просто выполняет требуемые условия (выравнивание, вставка обрезалок перед джампами), но в принципе никто не заставляет придерживаться именно её.
Коду в NaCl не доступны никакие системные вызовы или прерывания, но предоставляется какой-то свой очень урезанный API. Можно рисовать на экран, играть звук, при наличии плагина работать с OpenGL через очень тонкую прослойку. Обещали работу с вебкамерами и микрофонами через плагин для браузера. Работать с сырыми сокетами нельзя во имя безопасности, но что-то там обещали сделать специально для разработчиков мультиплеерных игр, быть может оно уже есть в этой версии SDK. Доступа к локальным файлам нет, сейвы рекомендуют хранить где-нибудь в сети.
Многопоточность есть by design, к тому же весь код кросс-платформенный (Win/Mac/Lin) с точностью до архитектуры процессора. В недрах гугла активно пилится LLVM-версия, которой и архитектура процессора будет побоку (про планы Эппла насчёт NaCl на своих железках ничего не знаю, сразу говорю).
Для ARM’а всё делается немного по-другому, и утверждалось, что потери там несколько меньше.
Как-то так.
|
|
Отправлено 16.05.2010 в 15:11
|
|
|
|
Отправлено 16.05.2010 в 16:47
|
|
Иван Терехов пишет:
>
>
Нигде инфы по интеграции SDK с различными IDE не встречалось? В Visaul Studio он вроде как по-умолчанию пытается интегрироваться, но я пользуюсь бесплатным софтом.
|
|
Отправлено 16.05.2010 в 20:12
|
|
Иван Терехов пишет:
> ...
Интересно.
Допустим я нашел адрес kernel32.dll, после этого я могу построить себе таблицу любых полезных функций и вызывать их. Чтобы функция сработала без обрезанного до 32 байт начала эти инструкции можно скопировать чтобы выполнились заранее.
Код вроде не будет ничем явно выделяться, неужели верификатор может 100% такое предотвратить?
Если что, я не изучал ни вирусы ни антивирусы, но исходя из их наличия меня просто поражает возможность безопасной оболочки :)
|
- Подписчики [675]
- Белый список [19]
- Черный список [3]
Вы можете читать группу, но не можете отвечать на сообщения и создавать новые темы.
Доступ для остальных:
| анонимы |
: могут читать |
| новые |
: могут читать |
| постоянные |
: полный доступ |
|
