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

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

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

cp /bin/sh /bin/sh.exe

/bin/sh.exe

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

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

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

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

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

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

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

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

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

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

революция ?

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

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

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

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

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

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

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

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

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

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

NaCl

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

+1. О том же подумал.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

NaCl

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

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

лучше кактус от ms чем анальный зонд от гугла

vga

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

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

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

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

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

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

prishel_potrollit

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

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

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 будет дописан строго фиксированный код проверки, который каждый раз будет проверяться при запуске. Сам будет дописан, вам ничего делать не нужно.

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.

FAQ Errata

Упс:

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

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

int a = foo(x, y);

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

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

int a = foo_ptr(x, y);

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

Те, кто осмысленно отказываются от убогого браузера ИЕ - теперь фанатики? Хорошая логика.

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

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

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

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

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

спасибо за FAQ

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

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

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

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

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

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