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.

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

программирование

Комментарии 20

besisland (besisland.name) № 1
Привет, платформозависимые сайты!
A.I. (sitnik.ru) № 2
Конечно только на NaCl писать сайт нельзя, но почему бы не сделать версию на JS и отдельно на NaCl для JS-приложений, которые очень требовательные.
Ну или JS-приложения, которые на JS просто не сделать, типа мощных граф. редакторов — там просто другого выбора не будет.
Да и покрытие NaCl такое огромное, что 99,9 % все компьютеров покрывает. Ну я могу вспомнить только какой-нить SPARC с Solaris.
Евгений Степанищев (bolknote.ru) автор № 4
Да и покрытие NaCl такое огромное, что 99,9 % все компьютеров покрывает. Ну я могу вспомнить только какой-нить SPARC с Solaris.

Это пока. В будущем что-то появится, а перекомпилить клиентские сайты будет некому (из того, что уже видно — x86-128).

Или вот, до сих пор где-то существуют владельцы предыдущих «Маков», которые на PowerPC. Их обделят :) Их же ещё должно быть достаточно в интернете, не могли же они сломаться разом при переходе «Эпл» на «Интел».

Евгений Степанищев (bolknote.ru) автор № 3
Привет, ага!

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

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

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

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

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

Недостатки есть.
Евгений Степанищев (bolknote.ru) автор № 5
Ого, оказывается, Windows 8 будет работать на IA-128. Хм. Я как-то забыл про эту платформу, тогда как существует Windows XP для IA-64, а значит и пользователи интернет на этой платформе.
Anonymous № 6
Если ещё x86 ↔ x86-64 можно как-то транслировать «на лету» (разработчики об этом говорят как о чём-то возможном в будущем), то в направлении x86 ↔ ARM делаться ничего не будет.

http://blog.chromium.org/2010/03/native-cl … ility.html
В марте объявлено про Portable NaCl, где решена проблема одного бинарника и нескольких архитектур.

Ной (sad-wind.ya.ru) № 8
Там же (в ролике) показывали интерпретатор Ruby, работающий в браузере.

Ruby я куда-то посеял (вроде был где-то), а вот быстрый Python в браузере лежит уже несколько лет по адресу http://ironpython.net/try/ или http://ironpython.codeplex.com/wikipage?ti … Title=Home (у меня не грузится что-то)

Высокая скорость. Никаких извращений для обеспечения безопасности. Поддержка винды и мака (ну и линукса..).

Ной (sad-wind.ya.ru) № 9

Комментарий для Евгения Степанищева:

Ого, оказывается, Windows 8 будет работать на IA-128.

А что такое «IA-128» ? =)

Евгений Степанищев (bolknote.ru) автор № 10

Комментарий для sad-wind.ya.ru:

А что такое «IA-128» ? =)

Itanium 128 бит.

Евгений Степанищев (bolknote.ru) автор № 11

Комментарий для sad-wind.ya.ru:

а вот быстрый Python в браузере лежит уже несколько лет по адресу http://ironpython.net/try/

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

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

Но за ссылку спасибо!

Евгений Степанищев (bolknote.ru) автор № 12
Комментарий для sad-wind.ya.ru:

Кстати, остаётся открытым вопрос как этот Silverlight IronPython сможет общаться с JavaScript (и обратно) и вообще вызывать всякое, например O3D, из себя.
think-alike (think-alike.livejournal.com) № 13
Как-то не понял, чем NaCl лучше залатанного-перелатанного ActiveX, кроме двух штучек для безопасности.
Евгений Степанищев (bolknote.ru) автор № 14
Тем, что адаптировать программы под NaCl проще? Тем, что это работает и для ARM тоже? Может быть тем, что это работает под кучу платформ и кучу браузеров? Или, может, потому что ActiveX — небезопасная шутка, а «хлорид натрия» — безопасное? :)
think-alike (think-alike.livejournal.com) № 15
Комментарий для Евгения Степанищева:

Надеюсь, что оно будет шустрее джавы, работающей тоже вроде как везде :)
Евгений Степанищев (bolknote.ru) автор № 16
Комментарий для think-alike.livejournal.com:

Оно на 3% менее шустрое, чем скомпилированный Си-код.
Ной (sad-wind.ya.ru) № 17
а потом просто встраиваете в браузер тегом 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 бит.

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

Евгений Степанищев (bolknote.ru) автор № 18

Комментарий для sad-wind.ya.ru:

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

Да ладно? http://dev.w3.org/html5/spec/Overview.html … ed-element

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

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

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

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

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

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

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

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

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

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

Ной (sad-wind.ya.ru) № 19

Комментарий для Евгения Степанищева:

Да ладно? http://dev.w3.org/html5/spec/O%E2%80%A6e-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.

Евгений Степанищев (bolknote.ru) автор № 20

Комментарий для sad-wind.ya.ru:

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

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

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

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

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

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

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

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