Google Native Client

Поиграл немного с Google Native Client — это плагин для браузера (поддерживаются Firefox, «Опера», «Сафари» и «Хром» и платформы Windows, Mac и Linux на x86, x86-64 и ARM).

Это плагин, который умеет исполнять скомпилированный бинарный (!) код в браузере. В каком-то смысле это напоминает ActiveX. Вы пишете бинарный код, компилируете его в специальной версии gcc, а потом просто встраиваете в браузер тегом EMBED.

Меня интересовало как тут соблюдается безопасность. Коду многое запрещено (по сути, всё, что разрешено — это эффективное использование процессорного времени, за остальным нужно обращаться в браузер через NPAPI или SRPC (Simple RPC)), но разработчики много говорят о том, что допускаются ассемблерные вставки.

Как так?

Ларчик, как оказывается, открывается просто и достаточно остроумно. Во-первых, разработчику запрещается использовать некоторые конструкции, например INT (вызов прерывания) и некоторые другие. Во-вторых, команды переходов модифицированы и это самое интересное.

Не знаю как там в процессорах ARM, а в x86 команды могут иметь разную длину, какая-нибудь «PUSH AX» занимает байт, «MOV AL,41» — два, « MOV AX,[BP+8]» — три и так далее. Если сделать переход не на первый байт команды (а, например, на второй байт команды «MOV AL, 41»), то окажется, что оставшаяся последовательность (возможно с байтами, которые идут дальше) тоже что-то означает (в случае «MOV AL, 41» второй байт будет «41», это команда «INC CX»).

Это даёт возможность замаскировать внутри команды любую запрещённую команду и выполнить её, сделав переход не на первый байт. Как Google Native Client защищает нас от этого? Очень просто.

В Ассемблере есть специальная команда — «NOP» (в x86 занимает один байт, её код — «90»), она не делает ничего. Все команды вашей программы выравниваются до 16 байт этой командой. То есть «MOV AL,41» будет дополнена 14-ю командами «NOP», а все переходы разрешаются только на границу этих 16-ти байт. Для этого у адреса перехода всегда отрезаются несколько младших бит.

Вторая опасность — код в данных, ведь почти любые последовательности байт это какой-то машинный код, таким образом можно запросто спрятать код внутри текста, а потом выполнить переход на этот текст. Понятно, что обладая возможностью ограничить переходы, эту проблему решить несложно — разносим код и данные на разные регистры сегментов и не даём коду переходить на данные. Тут ничего сложного, первый случай был интереснее.

Интересно, что код, контролирующий безопасность и реализующий SRPC, получился очень небольшой, в ролике на YouTube разработчик говорит то о 6000 строк, то о 6000 байт. В любом случае, то и другое — немного. Там же (в ролике) показывали интерпретатор Ruby, работающий в браузере. Это интересно, но не более, интереснее то, что код на Си (или там C++, неважно) пришлось менять очень мало, чтобы перекомпилировать его в Google Native Code.

Мне кажется, это интересный проект.

27 июня 2010 20:10

webdev

bolk (bolknote.ru)
27 июня 2010, 21:52, ответ предназначен besisland (besisland.name):

Привет, ага!

Если ещё x86 ↔ x86-64 можно как-то транслировать «на лету» (разработчики об этом говорят как о чём-то возможном в будущем), то в направлении x86 ↔ ARM делаться ничего не будет.

Т.е. компилить придётся 2-3 файла, это раз.

Второе — под не распространённые процессоры это работать не будет. Конечно, со SPARC очень мало заходят в веб, их можно сосчитать по пальцам, я думаю, так что это не аудитория. Но кому-то может быть обидно :)

Ну и скоро появится x86-128 (Windows 8 будет поддерживать), если транслятор x86↔x86-64↔x86-XXX, то придётся компилить четвёртый файл, а весь старый код, который студия уже сдала клиенту, перекомпилить будет некому.

Опять же. Сейчас есть x86-XX и ARM, появится в через год какой-нибудь SuperARMSVCSA с другой архитектурой и ещё за три года станет популярным. Кто для него исходники перекомпилит?

Недостатки есть.

Ной (sad-wind.ya.ru)
8 июля 2010, 15:57

а потом просто встраиваете в браузер тегом EMBED.

//не входящий в стандарт HTML...

Если я правильно понял идею, это IronPython, скомпиленный под Sirverlight.

Я бы сказал, что это IronPython с GUI на Sirverlight.

Сильверлайту далековато по скорости до Native Client,

На тяжёлых задачах C# (даже под неродным линуксом) работает в 2 раза медленнее простого С. В то, что NaCl медленнее всего на 3% верится слабо (учитываю изрядно разжиревший бинарный код), ну да ладно.

кроме того, Native Client хорош тем, что позволяет перевести в веб кучу уже написанного на Си/Си++ кода.

Silverlight хорош ровно этим же =) Позволяет использовать кучу написанного на C# кода (И вообще, использовать один и тот же код/библиотеки в Windows/Mac/Linux/XBox/Zune/Windows Mobile/браузерах). Также, сдаётся мне, что переносимость тут сильно лучше, чем у С++ (Я очень слабо верю в его кросплатформенность).

остаётся открытым вопрос как этот Silverlight IronPython сможет общаться с JavaScript (и обратно) и вообще вызывать всякое

C Javascript он общается замечательно. Напомню, что в Silverlight 1 (ко весобщему негодованию) Javascript бфл единственным языком скриптинга.

>А что такое "IA-128" ? =)
Itanium 128 бит.

Ты точно уверен в его существовании?

bolk (bolknote.ru)
9 июля 2010, 13:10, ответ предназначен Ной (sad-wind.ya.ru):

EMBED … не входящий в стандарт HTML...

Да ладно? http://dev.w3.org/html5/spec/O~~verview.html#th~~e-embed-element

В то, что NaCl медленнее всего на 3% верится слабо (учитываю изрядно разжиревший бинарный код), ну да ладно.

Это NOP, который ничего не делает, правда, занимает так, но зато попадает не один в конвеер, а сразу пучком.

На тяжёлых задачах C# (даже под неродным линуксом) работает в 2 раза медленнее простого С

Верно, но разница между нами в том, что тебе почему-то кажется, что это немного.

Silverlight хорош ровно этим же =) Позволяет использовать кучу написанного на C#

На Си написано на многие порядки больше кода, чем на C#

C Javascript он общается замечательно. Напомню, что в Silverlight 1 (ко весобщему негодованию) Javascript бфл единственным языком скриптинга.

Я имею ввиду JS браузера

Itanium 128 бит. Ты точно уверен в его существовании?

Мне кажется, это не вопрос веры. Microsoft несколько раз упоминали, что Windows 8 будет поддерживать этот процессор.

Ной (sad-wind.ya.ru)
9 июля 2010, 15:59, ответ предназначен bolk (bolknote.ru):

Да ладно? http://dev.w3.org/html5/spec/O…e-embed-element

Это не стандарт, а черновик. В стандарт HTML тег embed, насколько я знаю, не входил. Это просто очередной проприетарный нетскейпово/мозилловый тег.

Это NOP, который ничего не делает, правда, занимает так, но зато попадает не один в конвеер, а сразу пучком.

Ну как бы не зря есть дальние и близкие джампы. Процессорный кеш тоже, думаю не одобрит разувание объёмов кода чуть ли не на порядок.

Верно, но разница между нами в том, что тебе почему-то кажется, что это немного.

Ну пишут же программы на Perl/Python/PHP/Ruby (которые в 20-25 раз медленнее). Не говоря уже про Javascript/ActionScript. Я не вижу сильной необходимости в плагинах, которые осуществляют постоянные и очень тяжёлые вычисления, а вот получить преимущества за счёт возможностей .Net я бы не отказался.

На Си написано на многие порядки больше кода, чем на C#

Ну смотри... почти весь C# код юзабелен в Silverlight. А какая доля C кода работает через NPAPI или SRPC? Мне кажется, что всё равно придётся много всего переписывать под эту новую платформу.

Я имею ввиду JS браузера

Я тоже.

Мне кажется, это не вопрос веры. Microsoft несколько раз упоминали, что Windows 8 будет поддерживать этот процессор.

Я бы всё-таки назвал это слухами. Опять же странно, что этот слух о Microsoft - единственное событие, где котором упоминается IA-128.

bolk (bolknote.ru)
9 июля 2010, 18:17, ответ предназначен Ной (sad-wind.ya.ru):

Это не стандарт, а черновик. В стандарт HTML тег embed, насколько я знаю, не входил. Это просто очередной проприетарный нетскейпово/мозилловый те

VIDEO тоже не стандарт, тем не менее, во всех современных браузерах есть.

Ну как бы не зря есть дальние и близкие джампы. Процессорный кеш тоже, думаю не одобрит разувание объёмов кода чуть ли не на порядок.

Как бы там ни было, спорить не о чем, разработчики уже озвучили цифры.

Ну смотри... почти весь C# код юзабелен в Silverlight. А какая доля C кода работает через NPAPI или SRPC? Мне кажется, что всё равно придётся много всего переписывать под эту новую платформу

В том-то и смысл, что изменения минимальны. Это подтверждает, например, Quake для Native Client.

Я бы всё-таки назвал это слухами. Опять же странно, что этот слух о Microsoft - единственное событие, где котором упоминается IA-128.

Ну, мне всё равно. В любом случае, переход на 128 бит случится, с такими темпами развития, в ближайшие 5-7 лет.

Ваше имя или адрес блога (можно OpenID):

Текст вашего комментария, не HTML:

Кому бы вы хотели ответить (или кликните на его аватару)

Подсказка по написанию комментария

В комментариях можно применять следующую специальную разметку:

слово, обрамлённое в «звёздочки» выделяется *жирным*
ссылка становится ссылкой: http://bolknote.ru
ссылка в скобках также становится ссылкой, закрывающая скобка не захватывается: (http://bolknote.ru)
каждую строку цитаты следует начинать со знака «больше»:
> это цитата
> из двух строк
можно вставить картинку, залитую на один из сервисов: «Яндекс.Фотки», «Фликр» или «Пикплз». Для этого нужно вставить на страницу полный адрес вашей картинки на сервисе, он превратится в картинку:

http://fotki.yandex.ru/users/bolknote/view/274311?page=3