LINUX.ORG.RU

Google выпустил Native Client SDK

 , ,


0

0

Native Client - это кроссплатформенная технология с открытым исходным кодом от Google, позволяющая запуск нативного кода C/C++ в браузере. SDK основан на GNU Compiler Collection и доступен для Linux, Windows и Mac OS X. Поддерживаемые платформы x86, x86_64 и ARM. Разработчики заявляют, что технология Native Client безопаснее Flash и JavaScript, а так же значительно превосходит их по скорости выполнения. На текущий момент доступны клиент-плагины для браузеров Chrome, Safari, Firefox, и Opera.

>>> Подробности



Проверено: Aceler ()

Ответ на: комментарий от vga

Так что то я не врубаюсь :( Весь тред прочитал и не понял.

Те они встроили (свой) компилятор С/С++ в браузер что ли ?

mx__ ★★★★★ ()
Ответ на: комментарий от RedPossum

>как он в убунте exe-шник запустил? оно там особым образом компилируется?

cp /bin/sh /bin/sh.exe

/bin/sh.exe

А вообще МОНО тоже через лоадер работает

demmsnt ()
Ответ на: комментарий от mx__

Нет. Там просто еще есть в разработке LLVM, и это все путает. А если забыть про LLVM - то все просто. Компилится бинарь, особым образом. В этом скомпиленном коде нет некоторых инструкций, и вставлены проверки, которые запрещают делать все, что хочется.

На клиенте этот бинарник быстро проверяется верификатором, довольно простым, который проверяет, что плохих инструкций нет и проверки в нужных местах есть. Если все хорошо - запускается. Если нет - до свидания. Вот и все.

А в случае с LLVM - байткод, который докомпиливается на клиенте, с верификацией опять же. То есть где-то как ява, только AOT вместо JIT, если я правильно понял.

vga ★★ ()
Ответ на: комментарий от vga

Какая то чушь. Опять не понятно почему написано что только на С/C++ а если не дай бог тотже паскаль ?

Получается что у них просто спец компилятор встроенный в браузер. Если бы они работали с бином то встроили бы в браузер - гипервизор ( типа вбокса )

А вот на выходе этого спец компилятора как я понял будет тоже байт код ( хотя они его они почему то бином зовут ) и явно не обычный ехе это !

mx__ ★★★★★ ()
Ответ на: комментарий от RedPossum

Там в комментах по ссылке в новости есть следующее

portability, we're deeply committed to building a system that's platform neutral. Please see our previous post about Portable Native Client, a system for shipping a low level, processor-neutral representation of a Native Client module. We've built a NaCl compiler for ARM using the LLVM compiler, but we haven't shipped the ARM compiler or platform neutral wire format in the SDK yet.

То есть оно есть, но в СДК не включено. Сейчас в СДК генерируется только бинарники для писюков.

vga ★★ ()
Ответ на: комментарий от RedPossum

> да они пока ничего не решили. то ли LLVM пользовать, то ли не пользовать.

если судя по видио — то да... Nov/10/2009 ещё не решили ~__^

mkfifo ()
Ответ на: комментарий от mx__

> Получается что у них просто спец компилятор встроенный в браузер.

какаято маленькая часть от компилятора (верификатор +: сборщик, или чуть больше чем сборщик)

и явно не обычный ехе это


конешно не оыбчный :-) .. формат свой.. да и называются ".nexe" а не ".exe" файлы :-)

mkfifo ()
Ответ на: комментарий от mx__

Опять не понятно почему написано что только на С/C++ а если не дай бог тотже паскаль ?

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

Получается что у них просто спец компилятор встроенный в браузер.

Верификатор, а не компилятор, он только проверяет код, и ничего не преобразует.

Если бы они работали с бином то встроили бы в браузер - гипервизор ( типа вбокса )

Ну можно сказать, что это и есть очень примитивный гипервизор, все, что он не дает - это доступ к собственному коду, защитой сегмента.

А вот на выходе этого спец компилятора как я понял будет тоже байт код

Нет там спецкомпилятора, поэтому там то, что закачается с сервера и исполнится, ЕСЛИ успешно пройдет верификацию.

и явно не обычный ехе это !

Не обычный, да, обрезанный чтобы ничего плохого не мог сделать. Обычный не пройдет проверку в верификаторе.

vga ★★ ()
Ответ на: комментарий от vga

> Нет там спецкомпилятора, поэтому там то, что закачается с сервера и исполнится, ЕСЛИ успешно пройдет верификацию.


точнее да — компилятора нет совсем (если x86, arm, ...) ..

...я вот чото уже про LLVM тему развёл :-) . тамто уже ведь нада же будет (после проверка) скомпилировать окончательно!

mkfifo ()
Ответ на: комментарий от mkfifo

...я вот чото уже про LLVM тему развёл :-)

Ну ты правильно развел, потому что порт на LLVM уже существует, просто еще пока не совсем готов, и именно в этот релиз СДК его не включили. Но как я понимаю, можно самому собрать из исходников и поиграться.

vga ★★ ()

Про ноябрь 2009 года.. тогда у них был рабочий сервер, который выдавал картинку с апликухи без всяких плагинов, они поменяли архитектуру?

gh0stwizard ★★★★★ ()

очередное анальное проникновение :3

anonymous ()

А как интересно добиваются кросплатформенности при том что в разных осях могут быть ра
зные модели памяти как минимум. Все равно нужна будет прослойка и посути это будет низкоуровневый байткод. К тому же под экзотические платформы отлаживать придется каждое приложение отдельно а не только виртуальную машину

DNA_Seq ★★☆☆☆ ()
Ответ на: комментарий от DNA_Seq

> А как интересно добиваются кросплатформенности при том что в разных осях могут быть разные модели памяти как минимум. Все равно нужна будет прослойка и посути это будет низкоуровневый байткод.

мерзкий сан так засрал людям мозги своей говноявой, что теперь думают прослойка==байткод

модель памяти щас почти везде плоская

www_linux_org_ru ★★★★★ ()

всячески приветствую это изделие — оно предназначено для того же, что и ява/сильверлайт/флеш — выполнение недоверенного кода, но делает это быстро, в отличие от них

www_linux_org_ru ★★★★★ ()
Ответ на: комментарий от www_linux_org_ru

Ну допустим выделение памяти в линуксе начинается со старших адресов а в венде с младших и растет стек в разные стороны

DNA_Seq ★★☆☆☆ ()

Что-то непонятно, как они рендерили глобус - как выводили картинку. Используется специальное апи в песочнице?

WindowsUser ★★ ()
Ответ на: комментарий от anonymous

> Почему тебя это так волнует? Вендораст штоле?

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

hobbit ★★★★★ ()
Ответ на: комментарий от DNA_Seq

> Ну допустим выделение памяти в линуксе начинается со старших адресов а в венде с младших

странно выглядит, но даже если и так, то никто не мешает сделать свой malloc с фиксированным поведением

и растет стек в разные стороны

я что-то пропустил? мне казалось на x86 всегда в одну; да и закладываться на сторону роста в программе на с++ не есть хорошо

www_linux_org_ru ★★★★★ ()
Ответ на: комментарий от DNA_Seq

> растет стек в разные стороны

в си уже сто лет как два указателя на элементы *разных* массивов несравнимы, видимо в т.ч. потому, что массивы, лежащие в стеке, могут расти в/против стороны роста стека

www_linux_org_ru ★★★★★ ()
Ответ на: комментарий от WindowsUser

> Что-то непонятно, как они рендерили глобус - как выводили картинку. Используется специальное апи в песочнице?

Ага, апи - npapi pepper. Короче, получился а-ля флеш со своими АПИ, только можно использовать С библиотеки. Неплохо. Осталось только убедиться, что эти апи не содержат дырок :)

WindowsUser ★★ ()
Ответ на: комментарий от WindowsUser

Осталось только убедиться, что эти апи не содержат дырок :)

Хм ну они в ролике ноябрьском говорят что у них 600 строк кода. Пусть даже сейчас там 2000. Сравните это с флэшем или ява машиной, это ж ппц разница в не знаю сколько порядков )

Davinel ()
Ответ на: комментарий от hobbit

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

Для начала эта хрень явно будет в гугло-сервисах. Заходишь, тебе показывают табличку «скачайте chrome-frame или валите нафиг».

Davinel ()
Ответ на: комментарий от Davinel

Это только валидатор кода. Прибавь сюда все будущие API и будет примерно так же. Хотя предложенная модель выглядит более надёжной

anonymous ()

Интересно еще никому не пришло в голову реанимировать под этим соусом популярные в своё время ДОСовские игры, типа Ларри, Голд Аксе, УФО и т.п. на смартфонах (разрешение экрана как раз))). Хотя ДОСЕМУ был бы наверно лучше в этом плане.

shelA ()
Ответ на: комментарий от demmsnt

Безопасность за счет того, что в STDLIB нет функций доступа за пределы клетки...

А ещё за счёт того, что *(123) = 213; не уронит браузер.

Legioner ★★★★★ ()
Ответ на: комментарий от anonymous

> Это только валидатор кода. Прибавь сюда все будущие API и будет примерно так же. Хотя предложенная модель выглядит более надёжной

Большинство API, судя по доке, тоже в песочнице. Поэтому проблему могут составлять внешние апи (ну и сам верификатор, если чего пропустили), которые через SRPC дергаются (а также npapi). Вообщем, обычная проблема секурности браузеров.

Недостаток этой штуки по сравнению с ява/сильверлайт (в последнем, правда, не уверен) в отсутствии коммуникации с внешним миром «из коробки». Надеяться на сторонние плагины - оптимистично слишком...

WindowsUser ★★ ()
Ответ на: комментарий от www_linux_org_ru

видимо в т.ч. потому, что массивы, лежащие в стеке, могут расти в/против стороны роста стека

Во что будет компилиться конструкция char *p; ...; ++p; ?

Legioner ★★★★★ ()
Ответ на: комментарий от hobbit

> запихать NaCl и в IE.

NaCl

- Поваренная соль - подумал Штирлиц.

Соль, которую переварил Гугель и высрал в браузер, стала поваренной :)

vold ★★★★★ ()
Ответ на: комментарий от vga

vga

Ну а так ты получишь сразу три бинарника (x86, x86-64 и ARM), клиент загрузит нужный. В том же макосе что-то подобное, только бинарник один, универсальный, в который запихнуты все поддерживаемые платформы.

Я их получу написав один исходник? Русский докладчик честно сказал - если ассемблер - то пишите сами под конкретную платформу.

То есть, сейчас гугл предлагает компиляцию однго кода под 3 проца за свой счет. С некоторыми ограничениями.

Revetant ()
Ответ на: комментарий от vaulter

> А левый jmp в стек? :)

Виндузятник? или БСДишник?

У вас там всё ещё исполняемый стэк?

Led ★★★☆☆ ()
Ответ на: комментарий от prishel_potrollit

prishel_potrollit

За фанатиков из Гугла! А то 60% рынка так и будут жрать кактус.

Поверь, те самые 60% рынка так и продолжад жрать кактус.

Revetant ()

FAQ

Краткий FAQ для не-LLVM-версии (т.е. для того, что уже есть и великолепно работает).

1) Они чё-то там компилируют прямо на машине клиента?

Нет. Ничего. Загружается уже готовый бинарник, после чего по бинарнику с дикой скоростью проходится верификатор и просматривает бинарник на запрещенные инструкции. Если всё ОК, код выполняется нативно. Если не ОК — код просто не выполняется. Весь. Сразу.

2) Бинарник — это elf? exe? Или что? Под какую ОС бинарник?

Ни под какую. Бинарник — под ваш процессор, а системные вызовы, характерные для отдельных ОС, ему делать всё равно запрещено. Любые. Начисто. Полностью. У него есть лишь крохотный набор тех функций, которые ему предоставляет Native Client. Идеальная песочница для нативного кода.

3) А если я сделаю хитрожопый jmp или call в системную функцию ручками, к примеру, не по фиксированному адресу, а вычисляя его хитрожопым алгоритмом?

Если в коде встречается jmp или call, он проверяется. Критерии: прыгать можно ТОЛЬКО в фиксированный диапазон адресов и ТОЛЬКО с кратностью 16 байт (зачем — см. ниже). Если очень хочется прыгнуть по адресу, который программа вычислила сама, перед прыгом ОБЯЗАН быть код, который проверяет этот адрес. Строго фиксированный код (буквально несколько байт), заданный стандартом NC. Т.е. между «прибавить к этому указателю этот указатель» и «прыгнуть» ОБЯЗАТЕЛЬНО должны быть инструкции проверки этого адреса. Если хоть в одном месте их нет — ВЕСЬ код ВСЕЙ программы проваливает верификацию. И напоминаю для тех, кто забыл — прыгать в сегмент данных нельзя впринципе.

4) Но я намеренно переполнил стек, и затёр адрес возврата своим коварным адресом.

Адрес будет проверен ДАЖЕ если это адрес возврата из стека. Любой ret обязан иметь тот же самый код проверки адреса, что и jmp. Поэтому возврат из функции чуть-чуть медленнее (в целом на этих проверках средняя программа теряет около 5% перформанса).

5) Т.е. мне теперь всё переписывать?

Нет — этот код проверки дописывается модифицированной версией GCC самостоятельно. Вы просто компилируете своё приложение в модифицированной GCC. Перед КАЖДЫМ вашим jmp/call будет дописан строго фиксированный код проверки, который каждый раз будет проверяться при запуске. Сам будет дописан, вам ничего делать не нужно.

anonymous ()

FAQ, часть 2

6) А если я сам подковыряю эту версию GCC, чтобы оно не проверяло? Вперёд, это не сложно. Но ваш код не пройдёт верификацию в момент запуска. Всё просто.

7) Т.е. можно взять готовый elf/exe и запустить его в NC?

Нет. Вы берёте свой код, ПЕРЕСОБИРАЕТЕ его в модифицированном GCC, и уже потом спокойно запускаете. В противном случае код скорее всего не пройдёт верификацию (см. про проверки ранее).

8) А если верификатор бажит?

Это не флеш и не ява, где чёрт ногу сломит в 40 мегабайтах кода. Верификатор крохотный. Совсем крохотный. Каждый может вдумчиво его прочитать и разобраться, что уже сделали десятки специалистов по безопасности. Прочитайте и вы, если хотите. Особенно рекомендую гентушникам, очень поднимает ЧСВ (причём заслуженно, что редкость) =)

9) А если я обфусцирую встроенный дизассемблер, пользуясь тем, что под x86 инструкции имеют разную длину? К примеру, накладываю один код на другой (и по адресу X у меня оказывается нормальный, но бессмысленный код, а по смещённому X+1 в той же области памяти — вредоносный)?

Вы не сможете прыгнуть в такой код, потому что все адреса переходов обязательно выравниваются, а все переходы по вычесленным адресам обязательно проверяются на выравнивание. Модифицированная версия GCC обеспечивает это. Прыгнуть по невыровненному адресу не позволяет верификатор.

10) Т.е. код раздуется?

На несколько процентов, за счёт обязательных проверок и выравнивания адресов. Но с другой стороны, он и чуть-чуть уменьшится за счёт срезания OS-dependant-говна (привет виндузятникам). В худшем случае очень крупные приложения разбухают процентов на 20.

11) Признавайтесь, где подвох? Это заговор майкрософта и гугла, чтобы убить Линукс?

Нет. Это мощнейший удар по M$. До этого осной бедой Линукса было «я не могу отказаться от венды, потому что только там работает моя уютненькая игрушечка, в которой я мегазадрот». Теперь от операционной системы не зависит ВООБЩЕ ничего (ну ок, дрова разве что должны быть не кривыми, привет ATI). Любая игрушка, свистелка или перделка, написанная под NC внезапно будет работать на любой ОС. Больше никакого анального рабства школоты DirectX’ами. Больше никаких проблем с совместимостью. Для любых приложений NC венда просто совершенно никому не нужна, со всем её кривым API, своими закрытыми форматами и своими запатентованными протоколами.

Всем спасибо, конец FAQ.

anonymous ()

FAQ Errata

Упс:

Перед КАЖДЫМ вашим jmp/call будет дописан строго фиксированный код проверки, который каждый раз будет проверяться при запуске.

Имелось в виду «перед каждым, у которого адрес не константный». А вот вызов обычных функций, вроде

int a = foo(x, y);

будет исполняться с точно такой же скоростью, если foo — это обычная функция с фиксированным адресом. Замедление будет при выходе из foo, когда будет проверен адрес возврата. А адрес вызова проверяется перед запуском.

Для контраста:

int a = foo_ptr(x, y);

где foo_ptr — указатель на функцию. Здесь будет вставлен дополнительный ассемблерный код (буквально несколько инструкций), проверяющий, что по текущему значению foo_ptr хранится выровненный, урезанный до код-сегмента адрес. Если верификатор обнаружил вызов без этой проверки, программа проваливает верификацию.

anonymous ()
Ответ на: FAQ, часть 2 от anonymous

спасибо за столь концентрированные разъяснения.

получается, идея верификатора полезна не только для веба. можно предположить ось, в котором все приложения обязаны бы были компилироваться таким компилятором с проверками. и к каждой программе бы цеплялся некий профиль безопасности, который мог бы настраиваться юзером: этому приложению можно в сеть и в каталог /home/user/.app, а вот этому приложению - только картинки рендерить.

boo32 ()
Ответ на: комментарий от Reset

Месье такой большой ценитель анальных кактусов от ms?

Lumi ★★★★★ ()
Ответ на: комментарий от boo32

Да, получается именно это, попутно решается ещё огромный ворох проблем.

Lumi ★★★★★ ()
Ответ на: комментарий от pevzi

Убогим он был во времена 6й версии, сейчас вполне нормальный браузер. Всякие хромы и фф из него фичи даже тащат.

Reset ★★★★★ ()
Ответ на: FAQ Errata от anonymous

спасибо за FAQ

скачиваемые бинари как-то могут вызывать друг-друга? Т.е. можно ли организовывать код в библиотеки/пакеты/хрен его знает что? Возможность «калбэков» внутри бинаря есть?

И на сколько «богата» стандартная библиотека? Для чего пригодна - только для числодробилки, или ещё для чего?

yyk ★★★★★ ()
Ответ на: комментарий от Reset

Ой ну да, тащат, конечно (: ие сам-то изо всех сил старается догнать уже существующие браузеры, куда уж там. Успехи есть, правда не особо грандиозные.

pevzi ★★★★★ ()
Ответ на: комментарий от pevzi

например, запуск каждой вкладки в отдельном процессе в IE сто лет как появилась, потом только сделали в хроме, а в фф этим даже и не пахнет

Reset ★★★★★ ()
Ответ на: комментарий от hobbit

> К.О. подсказывает, что без поддержки пока ещё самого популярного обозревателя новой технологии не жить.

А почему без поддержки, когда есть chromeframe?

Aceler ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.