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 19:10

besisland (besisland.name)
27 июня 2010, 20:14

Привет, платформозависимые сайты!

A.I. (sitnik.ru)
27 июня 2010, 20:36, ответ предназначен besisland (besisland.name):

Конечно только на NaCl писать сайт нельзя, но почему бы не сделать версию на JS и отдельно на NaCl для JS-приложений, которые очень требовательные.
Ну или JS-приложения, которые на JS просто не сделать, типа мощных граф. редакторов — там просто другого выбора не будет.
Да и покрытие NaCl такое огромное, что 99,9 % все компьютеров покрывает. Ну я могу вспомнить только какой-нить SPARC с Solaris.

bolk (bolknote.ru)
27 июня 2010, 20: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 с другой архитектурой и ещё за три года станет популярным. Кто для него исходники перекомпилит?

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

bolk (bolknote.ru)
27 июня 2010, 21:00, ответ предназначен A.I. (sitnik.ru):

Да и покрытие NaCl такое огромное, что 99,9 % все компьютеров покрывает. Ну я могу вспомнить только какой-нить SPARC с Solaris.
Это пока. В будущем что-то появится, а перекомпилить клиентские сайты будет некому (из того, что уже видно — x86-128).

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

bolk (bolknote.ru)
27 июня 2010, 23:13

Ого, оказывается, Windows 8 будет работать на IA-128. Хм. Я как-то забыл про эту платформу, тогда как существует Windows XP для IA-64, а значит и пользователи интернет на этой платформе.

Anonymous (инкогнито)
27 июня 2010, 23:55

Если ещё x86 ↔ x86-64 можно как-то транслировать «на лету» (разработчики об этом говорят как о чём-то возможном в будущем), то в направлении x86 ↔ ARM делаться ничего не будет.
http://blog.chromium.org/2010/03/native-client-and-web-portability.html
В марте объявлено про Portable NaCl, где решена проблема одного бинарника и нескольких архитектур.

bolk (bolknote.ru)
28 июня 2010, 00:06, ответ предназначен Anonymous

Насколько я понял, используется байт-код LLVM?

Ной (sad-wind.ya.ru)
28 июня 2010, 02:10

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

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

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

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

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

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

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

а вот быстрый Python в браузере лежит уже несколько лет по адресу http://ironpython.net/try/
Если я правильно понял идею, это IronPython, скомпиленный под Sirverlight.

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

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

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

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

think-alike (think-alike.livejournal.com)
28 июня 2010, 12:00

Как-то не понял, чем NaCl лучше залатанного-перелатанного ActiveX, кроме двух штучек для безопасности.

bolk (bolknote.ru)
28 июня 2010, 12:49, ответ предназначен think-alike (think-alike.livejournal.com):

Тем, что адаптировать программы под NaCl проще? Тем, что это работает и для ARM тоже? Может быть тем, что это работает под кучу платформ и кучу браузеров? Или, может, потому что ActiveX — небезопасная шутка, а «хлорид натрия» — безопасное? :)

think-alike (think-alike.livejournal.com)
28 июня 2010, 13:27, ответ предназначен bolk (bolknote.ru):

Надеюсь, что оно будет шустрее джавы, работающей тоже вроде как везде :)

bolk (bolknote.ru)
28 июня 2010, 16:15, ответ предназначен think-alike (think-alike.livejournal.com):

Оно на 3% менее шустрое, чем скомпилированный Си-код.

Ной (sad-wind.ya.ru)
8 июля 2010, 14: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, 12:10, ответ предназначен Ной (sad-wind.ya.ru):

EMBED … не входящий в стандарт HTML...
Да ладно? http://dev.w3.org/html5/spec/Overview.html#the-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, 14: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, 17:17, ответ предназначен Ной (sad-wind.ya.ru):

Это не стандарт, а черновик. В стандарт HTML тег embed, насколько я знаю, не входил. Это просто очередной проприетарный нетскейпово/мозилловый те
VIDEO тоже не стандарт, тем не менее, во всех современных браузерах есть.
Ну как бы не зря есть дальние и близкие джампы. Процессорный кеш тоже, думаю не одобрит разувание объёмов кода чуть ли не на порядок.
Как бы там ни было, спорить не о чем, разработчики уже озвучили цифры.
Ну смотри... почти весь C# код юзабелен в Silverlight. А какая доля C кода работает через NPAPI или SRPC? Мне кажется, что всё равно придётся много всего переписывать под эту новую платформу
В том-то и смысл, что изменения минимальны. Это подтверждает, например, Quake для Native Client.
Я бы всё-таки назвал это слухами. Опять же странно, что этот слух о Microsoft - единственное событие, где котором упоминается IA-128.
Ну, мне всё равно. В любом случае, переход на 128 бит случится, с такими темпами развития, в ближайшие 5-7 лет.

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

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

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