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.
Мне кажется, это интересный проект.
Привет, платформозависимые сайты!
Комментарий для besisland.name:
Конечно только на NaCl писать сайт нельзя, но почему бы не сделать версию на JS и отдельно на NaCl для JS-приложений, которые очень требовательные.
Ну или JS-приложения, которые на JS просто не сделать, типа мощных граф. редакторов — там просто другого выбора не будет.
Да и покрытие NaCl такое огромное, что 99,9 % все компьютеров покрывает. Ну я могу вспомнить только какой-нить SPARC с Solaris.
Комментарий для besisland.name:
Привет, ага!
Если ещё x86 ↔ x86-64 можно как-то транслировать «на лету» (разработчики об этом говорят как о чём-то возможном в будущем), то в направлении x86 ↔ ARM делаться ничего не будет.
Т. е. компилить придётся 2-3 файла, это раз.
Второе — под не распространённые процессоры это работать не будет. Конечно, со SPARC очень мало заходят в веб, их можно сосчитать по пальцам, я думаю, так что это не аудитория. Но кому-то может быть обидно :)
Ну и скоро появится x86-128 (Windows 8 будет поддерживать), если транслятор x86↔x86-64↔x86-XXX, то придётся компилить четвёртый файл, а весь старый код, который студия уже сдала клиенту, перекомпилить будет некому.
Опять же. Сейчас есть x86-XX и ARM, появится в через год какой-нибудь SuperARMSVCSA с другой архитектурой и ещё за три года станет популярным. Кто для него исходники перекомпилит?
Недостатки есть.
Комментарий для sitnik.ru:
Это пока. В будущем что-то появится, а перекомпилить клиентские сайты будет некому (из того, что уже видно — x86-128).
Или вот, до сих пор где-то существуют владельцы предыдущих «Маков», которые на PowerPC. Их обделят :) Их же ещё должно быть достаточно в интернете, не могли же они сломаться разом при переходе «Эпл» на «Интел».
Ого, оказывается, Windows 8 будет работать на IA-128. Хм. Я как-то забыл про эту платформу, тогда как существует Windows XP для IA-64, а значит и пользователи интернет на этой платформе.
http://blog.chromium.org/2010/03/native-client-and-web-portability.html
В марте объявлено про Portable NaCl, где решена проблема одного бинарника и нескольких архитектур.
Комментарий для Anonymous:
Насколько я понял, используется байт-код LLVM?
Ruby я куда-то посеял (вроде был где-то), а вот быстрый Python в браузере лежит уже несколько лет по адресу http://ironpython.net/try/ или http://ironpython.codeplex.com/wikipage?title=SilverlightInteractiveSession%26referringTitle=Home (у меня не грузится что-то)
Высокая скорость. Никаких извращений для обеспечения безопасности. Поддержка винды и мака (ну и линукса..).
Комментарий для Евгения Степанищева:
А что такое «IA-128» ? =)
Комментарий для sad-wind.ya.ru:
Itanium 128 бит.
Комментарий для sad-wind.ya.ru:
Если я правильно понял идею, это IronPython, скомпиленный под Sirverlight.
Сильверлайту далековато по скорости до Native Client, кроме того, Native Client хорош тем, что позволяет перевести в веб кучу уже написанного на Си/Си++ кода.
Но за ссылку спасибо!
Комментарий для sad-wind.ya.ru:
Кстати, остаётся открытым вопрос как этот Silverlight IronPython сможет общаться с JavaScript (и обратно) и вообще вызывать всякое, например O3D, из себя.
Как-то не понял, чем NaCl лучше залатанного-перелатанного ActiveX, кроме двух штучек для безопасности.
Комментарий для think-alike.livejournal.com:
Тем, что адаптировать программы под NaCl проще? Тем, что это работает и для ARM тоже? Может быть тем, что это работает под кучу платформ и кучу браузеров? Или, может, потому что ActiveX — небезопасная шутка, а «хлорид натрия» — безопасное? :)
Комментарий для Евгения Степанищева:
Надеюсь, что оно будет шустрее джавы, работающей тоже вроде как везде :)
Комментарий для think-alike.livejournal.com:
Оно на 3% менее шустрое, чем скомпилированный Си-код.
//не входящий в стандарт HTML...
Я бы сказал, что это IronPython с GUI на Sirverlight.
На тяжёлых задачах C# (даже под неродным линуксом) работает в 2 раза медленнее простого С. В то, что NaCl медленнее всего на 3% верится слабо (учитываю изрядно разжиревший бинарный код), ну да ладно.
Silverlight хорош ровно этим же =) Позволяет использовать кучу написанного на C# кода (И вообще, использовать один и тот же код/библиотеки в Windows/Mac/Linux/XBox/Zune/Windows Mobile/браузерах). Также, сдаётся мне, что переносимость тут сильно лучше, чем у С++ (Я очень слабо верю в его кросплатформенность).
C Javascript он общается замечательно. Напомню, что в Silverlight 1 (ко весобщему негодованию) Javascript бфл единственным языком скриптинга.
Ты точно уверен в его существовании?
Комментарий для sad-wind.ya.ru:
Да ладно? http://dev.w3.org/html5/spec/Overview.html#the-embed-element
Это NOP, который ничего не делает, правда, занимает так, но зато попадает не один в конвеер, а сразу пучком.
Верно, но разница между нами в том, что тебе почему-то кажется, что это немного.
На Си написано на многие порядки больше кода, чем на C#
Я имею ввиду JS браузера
Мне кажется, это не вопрос веры. Microsoft несколько раз упоминали, что Windows 8 будет поддерживать этот процессор.
Комментарий для Евгения Степанищева:
Это не стандарт, а черновик. В стандарт HTML тег embed, насколько я знаю, не входил. Это просто очередной проприетарный нетскейпово/мозилловый тег.
Ну как бы не зря есть дальние и близкие джампы. Процессорный кеш тоже, думаю не одобрит разувание объёмов кода чуть ли не на порядок.
Ну пишут же программы на Perl/Python/PHP/Ruby (которые в 20-25 раз медленнее). Не говоря уже про Javascript/ActionScript. Я не вижу сильной необходимости в плагинах, которые осуществляют постоянные и очень тяжёлые вычисления, а вот получить преимущества за счёт возможностей .Net я бы не отказался.
Ну смотри... почти весь C# код юзабелен в Silverlight. А какая доля C кода работает через NPAPI или SRPC? Мне кажется, что всё равно придётся много всего переписывать под эту новую платформу.
Я тоже.
Я бы всё-таки назвал это слухами. Опять же странно, что этот слух о Microsoft — единственное событие, где котором упоминается IA-128.
Комментарий для sad-wind.ya.ru:
VIDEO тоже не стандарт, тем не менее, во всех современных браузерах есть.
Как бы там ни было, спорить не о чем, разработчики уже озвучили цифры.
В том-то и смысл, что изменения минимальны. Это подтверждает, например, Quake для Native Client.
Ну, мне всё равно. В любом случае, переход на 128 бит случится, с такими темпами развития, в ближайшие 5-7 лет.