Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 50
Лучше расскажите как эту штуку отключить. (вижу по дефолту пока отключена)
Вот только новых дыр с нативным кодом мне не хватало…
Скоро понадобиться ключ запуска чтобы ее отключать а не включать?
Вот только новых дыр с нативным кодом мне не хватало…
Скоро понадобиться ключ запуска чтобы ее отключать а не включать?
Достаточно не устанавливать расширения, которые требуют «Полный доступ к данным Вашего компьютера». Такие расширения и сейчас могут выполнять нативный код.
Опасность чую я с этой нативщиной в браузере…
Ну да, для них нет никаких песочниц, поэтому браузер и предупреждает. С NPAPI я когда то делал расширение Download It, которое слушало весь входящий к пользователю трафик и выгребала из него ссылки на видео файлы, получился универсальный загрузчик видео. Но проблема в том, что я использовал API из WinXP, соответственно расширение стабильно работало только под WinXP, под Win7 работа зависела от разрядности ОС и прав пользователя, под Win8, Linux и MacOS вообще никак не работало.
Как это нет? Вся идея native client в том, что создать для него песочницу намного проще, чем написать интерпретатор сложного языка без ошибок, позволяющих выполнять произвольный код.
Единственное ограничение, которое я заметил, при использовании Native Client — ручная проверка загружаемого расширения в магазин (обновление вроде без проверки, не помню точно). Каких либо ограничений в возможности выполнения нативного кода я не обнаружил.
Оу, извиняюсь, почему то посчитал, что Native Client и NPAPI — это одно и тоже, на самом деле нет. И песочницы нет в NPAPI.
А при установке приложений вы чувствуете себя полностью защищенным?
Здесь тоже самое, только вы разрешаете запуск приложения в оболочке другого приложения (браузера)
Здесь тоже самое, только вы разрешаете запуск приложения в оболочке другого приложения (браузера)
Код запускается в песочнице, поэтому ничего плохого с вашей системой сделать не может. В Гугле учли уроки ActiveX.
Даже в яве и жс (их машинах и интерпретаторах конечно же) находят уязвимости, что можно говорить про нативный код вообще?
Native Client накладывает ограничения, которые гарантируют, что программа не может читать, писать или передавать управление на память за пределами песочницы. Поэтому испортить что-то она может не в большей степени, чем JS код.
Вы сами в это верите? Когда яву делали тоже считали что ВМ не обойти а оно он как вышло…
Да, я читал статьи о том, как реализован NaCl, и не смог придумать, как скомпрометировать защиту песочницы.
Если найдут баг в runtime компонентах Chrome, его можно будет использовать и из JS, и из NaCl. Но обойти песочницу что в Java, что в NaCl я считаю невозможным без использования багов в Runtime library.
Если найдут баг в runtime компонентах Chrome, его можно будет использовать и из JS, и из NaCl. Но обойти песочницу что в Java, что в NaCl я считаю невозможным без использования багов в Runtime library.
Справедливости ради надо отметить следующий момент. Песочница не позволяет писать за пределами выделенной зоны памяти и выполнять произвольный код. Но чтение памяти по произвольным адресам было возможно (в NaCl, как дела с этим в PNaCl не в курсе).
В текущей версии это не так: для любого доступа к памяти гарантируется, что он не выйдет за пределы песочницы. Пруфы: для ARM, для x86-64.
Да, вы правы. Для x86_64 они выделяют регион размером 84(!) гига в адресном пространстве процесса, при этом логически все регистры 32 битные (84 гига как раз достаточно, чтобы не дать процессу выпрыгнуть за пределы песочницы с учетом особенностей адресации x86).
На арме каждый доступ к памяти (как на чтение так и на запись) предваряется обнулением старших бит указателя.
Значит все хорошо, можно спать спокойно)
На арме каждый доступ к памяти (как на чтение так и на запись) предваряется обнулением старших бит указателя.
Значит все хорошо, можно спать спокойно)
Ну вот они, Adobe VM и JVM, и вернулись.
«Внезапно» Гугл с Мозиллой поняли, что Javascript слишком сложный и медленный. Нужен байт-код (пусть даже его и назовут «нативным») и виртуальная машина интегрированная в браузер.
«Внезапно» Гугл с Мозиллой поняли, что Javascript слишком сложный и медленный. Нужен байт-код (пусть даже его и назовут «нативным») и виртуальная машина интегрированная в браузер.
А что вы предлогаете? Люди хотят под браузеры писать rich applications как под desktop. Вы уверены, что можно обойтись скриптовым языком второсортного качества и даже необзавестись для него инфраструктурой?
Да нет, смысл комментария в том, что Гугл вместе со всеми остальными (в том числе Apple) гнобили яву и флеш за то, что они мол не могут проверить байт-код на «опасные» инструкции. А теперь вот внедряет свой.
А понял. Кстати по поводу опасных инструкций, то PNaCl слегка лучше Java так, как происходит статическая проверка кода на системные вызовы и доступ к памяти в то время, как в Java проверки динамические at runtime, что конечно чревато багами.
Плюс PNaCl семантически на пару порядков проще джавы. Ни тебе классов, ни GC, ни JIT со сложными оптимизациями, типичными для class-based language. Это просто портабельный ассемблер.
Не сказать, что это такой уже плюс. Для веб-разработки нужен высокоуровневый язык с широким функционалом и поддержкой позволяющей сосредоточиться на разработке, а не низкоуровневой рутине. Построить такой язык на JVM — раз плюнуть. И даже не нужно использовать классы, если так уж хочется. Вон Clojure — вообще lisp. А вот авторам PNaCl языков еще придется много велосипедов переизобрести.
Похоже, в ближайшие несколько лет NaCl и Asm.js будут сосуществовать и конкурировать между собой.NaCl уже много лет доступен лишь приложениям браузера Chrome. Пока он не станет общедоступным, как тот же Flash, то толку от него?
Native Client на мой взгляд концептуально правильнее и быстрее. Но так как asm.js работает по крайней мере во всех современных браузерах, то пусть будет хотя бы он.
А почему он концептуально правильнее на ваш взгляд?
Потому что asm.js выглядит как костыль со своими |0 и прочим. JavaScript является прослойкой, и он все равно компилируется в нативный код. Его сложно или невозможно оптимизировать до уровня NaCl. А NaCl уже является нативным. Кроме того, NaCl уже поддерживает Mono, насколько я помню, т.е. на C# под него можно писать. (Под JavaScript конечно тоже можно, но это тоже более костыльно. О том как этот сделать, кстати, написано в одной моей статье).
Асм победит.
Асм — это не нативщина, а просто JS, выполняющийся полегче. Следовательно, нет вирусов и не требует особых разрешений.
Асм реализовать проще, потому что можно использовать парсер JS, а соль требует полного написания с нуля.
Асм полностью обратно совместим.
Асм — это не нативщина, а просто JS, выполняющийся полегче. Следовательно, нет вирусов и не требует особых разрешений.
Асм реализовать проще, потому что можно использовать парсер JS, а соль требует полного написания с нуля.
Асм полностью обратно совместим.
Я имею в виду, что реализовать разработчиками браузеров проще, а не писать на нём.
Реализовать проще? NaCl получается как плагин, основное уже реализовано Google, так же как и Flash.
было бы интересно посмотреть на ваши бенчмарки
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Поддержка Portable Native Client появилась в Chrome. Кто победит в гонке за нативным быстродействием — PNaCl или Asm.js?