Comments 121
Вы не могли бы пояснить, за счет чего планируется получить безопасность?
Хм. Это как бы ни о чем. Ну да, простой байткод — надежный байткод, но:
- значит ли это, что доступа у этого байткода никуда не будет? Ну т.е., страницы с других доменов, веб-камера, файлы, и все прочие ресурсы, которые в песочнице должны быть доступны не всем, и как правило только свои?
- если доступ все же будет, то должна быть кроме простоты какая-то модель безопасности. А ее что-то не видно (я тут спрашиваю, а не утверждаю). Какие-то модели прав для источников кода — коду вот отсюда можно то и это, а коду отсюда — нельзя ничего.
- а если не будет — то чем тогда байткод вообще будет заниматься?
Вообще я конечно не специалист по web security, может я просто не понимаю вопроса.
Обратите внимание что в списке post-MVP features (т.е. то что сейчас в разработке) обозначена Web Content Security Policy.
Ну, если это числодробилка — то с чего тут обещать безопасность? 2*2 и так всегда было безопасно :) Хотя если вдуматься, при наличии доступа к потокам и памяти устроить DoS уже должно быть возможно.
2*2 и так всегда было безопасно :)
Не всегда :) Например, переполнение стэка может быть с занесением 2 в область с чувствительными данными или кодом.
Позаботились о безопасности для подобных случаев.
А кстати, ошибку… exceptions же вроде пока нет, это в каком смысле, в том что wasm не может по своей инициативе выкинуть? Т.е. что будет дальше, функция завершается, в javascript в месте вызова можно написать try/catch?
Отчасти проблема безопасности Java заключалась в том, что она пыталась такие случаи отловить и дать программе шанс как-то восстановиться. Код получался сложным и в нём была куча дыр.
Код «если у нас всё плохо, то закрыть нафиг процесс не дав никому никаких шансов» — гораздо проще и, будем надеяться, правильнее и безошибочнее.
Как уже говорилось — очень вынушительный процент дыр в Java как раз в этом месте, так что в «боевом режиме» — это перебор.
А на тему «сдох твой код и поминай как звали» — так в Android'е и в ChromeOS, к примеру, твой процесс просто могут закрыть «без предупреждения» из-за того, что кто-то игрушку захотел запустить, так что ваша программа по-любому должна отрабатывать эту сутацию, а если она к ней готова — то зачем лишний, потенциально весьме небезопасный, код?
В стандарте нет, в реализациях обычно можно отследить что-нибудь в консоли.
Так это на клиентской машине, а мне-то, разработчику, как об этом узнать с подробностями в виде дампов всяких и тому подобного?
А на тему «сдох твой код и поминай как звали» — так в Android'е и в ChromeOS, к примеру, твой процесс просто могут закрыть «без предупреждения» из-за того, что кто-то игрушку захотел запустить, так что ваша программа по-любому должна отрабатывать эту сутацию, а если она к ней готова — то зачем лишний, потенциально весьме небезопасный, код?
Не, не в этом прикол. Если приложение убито из-за ошибки какой-то в твоем коде — как об этом узнать?
Так это на клиентской машине, а мне-то, разработчику, как об этом узнать с подробностями в виде дампов всяких и тому подобного?От браузера зависит. ChromeOS предоставляет интерфейс, вроде у Microsoft'а тоже что-то такое есть.
Не, не в этом прикол. Если приложение убито из-за ошибки какой-то в твоем коде — как об этом узнать?Запустить на своей машине? Самый надёжный метод, однако.
Из компиляторов самый продвинутый это Emscripten, он собирает WASM из C/C++. Кроме того, в Emscripten для WASM уже адаптировано много стандартных и популярных библиотек. При сборке кода в WASM происходит сборка как в варианте со «статической компиляцией» — весь используемый код всех библиотек помещается внутрь, размер WASM при этом конечно может получиться большим. Для «поддержки» работы WASM Emscripten также генерит кучу обёрток/клеевого кода на JavaScript.
Помимо WASM, в качетве альтернативы, Emscripten умеет компилить в asm.js, результат работает так же как WASM (возможно, немного медленнее) и работает на бОльшем наборе браузеров.
Есть и другие компиляторы кроме Emscripten, например, AssemblyScript компилирует в WASM из TypeScript. С деталями его работы я НЕ знаком, не приходилось использовать.
Есть и другие компиляторы кроме Emscripten
Я бы сказал, что их уже довольно много. Rust вроде можно, под LLVM какая-то поддержка wasm как целевой платформы (а значит потенциально сразу много языков). Есть там всякие проблемы, типа той, что нет пока GC, и если каком-то языку это нужно — надо тащить реализацию с собой. Но в целом выглядит так, что как только реализация самой виртуальной машины устоится, есть шанс получить сразу много компиляторов.
Мы Emscripten'ом собираем сразу в asm.js и wasm, в зависимости от того, поддерживает браузер wasm, загружаем wasm или asm.js код.
WASM это просто байткод для виртуальной машины.
Сама виртуальная машина — нативная или реализована на JS?
найтивный код процессора… Любопытно. И что, точнее как тогда, хотя всё-же что тогда обеспечивает кросплатформенность?
По хэшу там или по дате сравнивать и решать, обновлять перевод или старый прилетел?
В целом, похоже, отдано на откуп производителя браузера, нефункциональные требования к реализации отсутствуют.
Почему потребовалось разрабатывать целиком заново, вместо того чтобы взять JVM и доработать с учетом безопасности необходимой для браузера?
Вот почему-то не захотелось им затаскивать Java runtime прямо в браузер.
Google предлагал ещё NaCl и PNaCl — это по сути LLVM back-end затаскивается в браузер. Mozilla тоже сказала нам так не интересно.
Про NaCl не знаю, не сталкивался, возможно там свои проблемы были.NaCl — прекрасный пример того, как технически грамотные решения умирают из-за политики.
Изначально — это было безопасное кроссплатформенное (но привязанное к конкретному CPU!) решение с прямым доступом к DOM и поддержкой legacy API.
Потом Mozilla встала «в позу» и NaCl оказался привязан к Хрому.
После этого Гугл охре-, нет оху-, или, пожалуй, офи-… ладно — решил убрать прямой доступ к DOM и legacy API, тоже. Под лозунгом «асинхронность — наше всё» продукт лишили почти всех фич, кроме возможности исполнять нативный код.
После чего решили, что и этого — слишком много, так что нужно и эту возможность убрать тоже и оставить её только для ChromeOS.
В результате получили кастрата без фич, но с кучей недостатоков. У которого оставался один мааааленький плюсик: возможность исполнять нативный код под ChromeOS. Когда ChromeOS получил поддержку APK этот плюс перестал котироваться тоже.
Посмотрим как WASM закапывать будут…
Посмотрим как WASM закапывать будут…
Это вряд ли. Unity поддерживает WASM и Asm.js. Так же это позволяет подключать библиотеки на C/C++.
А потом — ну эта… не шмогла я, не шмогла…
Да и не в этом дело: Java вон вообще проприетарной долгое время была (как и .NET) — и ничего, вполне используется. Проблема была в том, что изначально постулировалось, что будет простое портирование старых программ, но в результате всем было предложено использовать только и исключительно асинхронный PPAPI.
Технология портирования старых программ путём переписывания их на новый API — это круто, конечно, но в этом случае можно, как бы, и без PNaCl'а обойтись…
Если говорить о конкретике, то JVM это продукт от Sun, вещь в себе.
Что, простите? Уже много лет как OpenJDK, направо и налево. Какая нафиг вещь в себе, когда исходники открыты по большей части, и давно?
Против всего остального, впрочем, особых возражений нет.
Как минимум лучше тем, что в браузерах вебасм из коробки, не требует от пользователя дополнительных действий по установке, активации, обновлению и т. п. Есть подозрение, что более легковесная подсистема получится, по сравнению даже с урезанной JVM. Ну и нет привязки к корпорации одной известной.
Сейчас-то поезд уже ушел…
кстати, какие там дыры? Чисто из любопытства спрашиваюМногочисленные. Во тут — 543 штуки. И это — только вершина айсберга, только то, что зарегистрировано как уязвимость. А уж сколько есть таких, которые проходят как «просто ошибка»… ни в сказке сказать, ни пером описать…
Ну, а если JVM для подмножества Java, с ограничениями на возможные косяки?Так это Андроид и получится! Зачем нам ещё один?
Вот если бы это лет 10 назад сделали — в этом был бы смысл. А сейчас -у же нет.
Доработать с учетом безопасности далеко не так просто. А так, если уж совсем примитивно посмотреть — то лучше простотой байткода и реализации виртуальной машины. Что это даст в конечном счете — пока вопрос открытый.
2. а откуда у вас именно 10-15%? или это просто из моего же текста? я кстати взял из одного из ответов со StackOverflow — чувак там очень авторитетно говорил про 10%, без всякого подтверждения фактами конечно.
Уже есть Unity
Обещает ли данная технология использование других языков программирования на фронте?
К примеру писать на Python, прогонять исходник через компилятор, который выдает на выходе бинарник WebAssembly?
Но сейчас пока предложенная модель выполнения довольно ограничена и лучше всего подходит для C/C++. В частности, пока нет сборщика мусора, реализацию которого конечно можно затащить внутрь WASM, что несколько увеличит его объём. Я не изучал подробно что ещё из других языков есть, но по-моему, большая часть это скорее эксперименты чем что-то production ready.
Все языки, которые могут собираться с помощью LLVM
— вот тут вопрос допустим я хочу собирать Pascal-код, LLVM frontend давно есть, но мне же тут придётся городить свой toolchain, верно?
Вопрос у меня не об этом. Для C/C++ Emscripten уже предоставляет всё готовое. Но для других языков (даже если они полностью поддерживаются LLVM) видимо придётся писать свои скрипты сборки?
Например, rust умеет напрямую собирать wasm.
Вы про это?
Лично у нас приложение написано на C++ и включает интерпретатор Lua.
Нативные модули нужно компилировать для каждой платформы. С этим часто бывают проблемы.
А WebAssembly — кроссплатформенный. Можно собрать его один раз и запускать на любой системе где есть Node.
Но, когда вы пишете свое приложение, то свой сервер вы обычно знаете, и платформа у вас выбрана одна.
При чём тут вообще Node к webassembly? Node — JavaScript рантайм, базирующийся на V8. А V8 — это движок ECMAScript, а вовсе не WASM.
А V8 — это движок ECMAScript
Там внутри есть компилятор JS в байткод. И исполняет он внутри байткод(V8 под капотом). Просто компилируем один байт код в другой и получаем профит.
V8 — это движок ECMAScript, а вовсе не WASM
Вы не правы. V8 также поддерживает WebAssembly.
Поэтому Node.js получает поддержку WASM практически бесплатно. В общем-то она уже есть, в качестве экспериментальной фичи за флагом
Базовые либы std вполне работают, однако есть нюансы, вроде неработающего setlocale для компонент времени/чисел.
#include <iostream>
#include <functional>
#include <algorithm>
#include <vector>
using namespace std;
int in_array(const store[], const int storeSize, query) {
for (size_t i=0; i<storeSize; ++i) {
if (store[i] == query) {
return i;
}
}
return -1;
}
экспортируем в
(module
(table 0 anyfunc)
(memory $0 1)
(export "memory" (memory $0))
(export "in_array" (func $_Z8in_arrayPKiii))
(func $_Z8in_arrayPKiii (param $0 i32) (param $1 i32) (param $2 i32) (result i32)
(local $3 i32)
(block $label$0
(block $label$1
(br_if $label$1
(i32.eqz
(get_local $1)
)
)
(set_local $3
(i32.const 0)
)
(loop $label$2
(br_if $label$0
(i32.eq
(i32.load
(get_local $0)
)
(get_local $2)
)
)
(set_local $0
(i32.add
(get_local $0)
(i32.const 4)
)
)
(br_if $label$2
(i32.lt_u
(tee_local $3
(i32.add
(get_local $3)
(i32.const 1)
)
)
(get_local $1)
)
)
)
)
(return
(i32.const -1)
)
)
(get_local $3)
)
)пытаемся применить и использовать в nodejs 8.4
var wasmCode = new Uint8Array([0,97,115,109,1,0,0,0,1,136,128,128,128,0,1,96,3,127,127,127,1,127,3,130,128,128,128,0,1,0,4,132,128,128,128,0,1,112,0,0,5,131,128,128,128,0,1,0,1,6,129,128,128,128,0,0,7,157,128,128,128,0,2,6,109,101,109,111,114,121,2,0,16,95,90,56,105,110,95,97,114,114,97,121,80,75,105,105,105,0,0,10,190,128,128,128,0,1,184,128,128,128,0,1,1,127,2,64,2,64,32,1,69,13,0,65,0,33,3,3,64,32,0,40,2,0,32,2,70,13,2,32,0,65,4,106,33,0,32,3,65,1,106,34,3,32,1,73,13,0,11,11,65,127,15,11,32,3,11]);
var wasmInstance = new WebAssembly.Instance(WebAssembly.Module(wasmCode));
exports.in_array = wasmInstance.exports._Z8in_arrayPKiii;
подключаем хотим протестировать производительность
const array_helper = require('./lib/helpers/in_array/index');
let data = [1,876,324, 3424,234234,234234, 555];
var suite = new Benchmark.Suite;
console.log(array_helper.in_array(data, data.length, 234234)); // ответ всегда -1;
suite.add('test in array', function() {
array_helper.in_array(data, data.length, 234234) > -1;
}).add('indexof', function() {
data.indexOf(234234) > -1;
})
.on('cycle', function(event) {
console.log(String(event.target));
})
.run();
я конечно не шарю в с++ но сравнить а+б могу.
Вы вызываете поиск в массиве из 7 элементов сотни раз. Попробуйте сделать массив из десятков тысяч элементов и померить на нем
Операция вызова WASM кода из JS — дорогая. Чем меньше таких переходов, тем быстрее ваш код.
Ну для начала нужно понять почему поиск внутри цикла не работает, а дальше можно и на большом массиве проверить.
Пока не вижу плюсов в wasm, раз такая дорогая операция вызова, даже для массива не годится.
Я не использую обход массива на десятки и сотни тысяч элементов, эффективней будет сделать хэш массив.
Пока не вижу плюсов в wasm, раз такая дорогая операция вызова, даже для массива не годится.Это примерно как сказать: пока не вижу смысла в аэробусах и боингах — на посадку нужно являться за 40 минут до вылета, а мне на дачу на машине ехать час. Почему с ними люди так носятся?
Если в вашей задаче нет «тяжёлых» вычислений и всё время уходит на общение с SQL-серверами или ещё чем-нибудь, то толку от wasm'а не будет, это правда.
Использовать WebAssembly только для того, что бы писать бизнес логику для странички на любимом Rust вместо ненавистного джаваскрипта, кажется большим оверхедом.
Вот именно. Большинство языков транслируются в JS и сегодня, поэтому WebAssembly прорыва здесь не сделает. Перевод на нативный код ускоряет операции над примитивами, а коллбеки и вызовы DOM по определению будут медленными.
Если перевести гипотетическое веб-приложение на WASM, то можно получить результат как у первого комментатора sanchezzzhak, когда расходы на прокидывание объектов туда и обратно сожрут все преимущество нативного кода.
В Гитхабе WebAssembly есть issue Webasm can replace Javascript in browser?, в которой приводятся похожие соображения.
а коллбеки и вызовы DOM по определению будут медленными.
Можно же не с DOM работать, а с виртуальным DOM как в ReactJS.
В Гитхабе WebAssembly есть issue Webasm can replace Javascript in browser?, в которой приводятся похожие соображения.
Никто никогда не говорил, что это замена JS. Asm.js был сделан именно для использования сторонних языков(C/C++) в браузере. WebAssembly пришел на замену Asm.js. И мы при использовании wasm получили 30 fps на iOS, в то время когда Asm.js выдавал 4fps.
Не надо придумывать, этот класс вполне существует. Чем меньше нужно взаимодействовать с пользователем (кнопки, поля ввода), тем больше выгоды принесет WASM.
Однако для типичного сценария "форма с валидацией и отправкой на сервер" WASM выглядит оверкиллом.
общение с сервером через websocket по бинарному протоколу (данные из websocket напрямую кидаем в WASM и расшифровываем уже там).
Это и в JS неплохо делается.
Подскажите как правильно скомпилировать .wasm из .c файла?
Взял пример из статьи:
int fib(int n)
{
if (n == 0) { return 0; }
else
{
if ((n == -1) || (n == 1)) { return 1; }
else
{
if (n > 0) { return fib(n - 1) + fib(n - 2); }
else { return fib(n + 2) - fib(n + 1); }
}
}
}Компилирую так же как в статье:
emcc -O1 fib.c -g -o fib.html -s WASM=1 -s NO_EXIT_RUNTIME=1 -s NO_FILESYSTEM=1 -fno-exceptions -fno-rtti --llvm-lto 1Получаю .wasm файл размером 27 кб :( Как получить массив как в примере выше:
[0,97,115,109,1,0,0,0,1,134,128,128,128,0,1,96,1,127,1,127,3,130,128,128,128,0,1,0,4,132,128,128,128,0,1,112,0,0,5,131,128,128,128,0,1,0,1,6,129,128,128,128,0,0,7,144,128,128,128,0,2,6,109,101,109,111,114,121,2,0,3,102,105,98,0,0,10,203,128,128,128,0,1,197,128,128,128,0,1,1,127,2,64,32,0,65,1,106,34,1,65,3,79,13,0,32,1,65,2,116,65,12,106,40,2,0,15,11,2,64,32,0,65,1,72,13,0,32,0,65,127,106,16,0,32,0,65,126,106,16,0,106,15,11,32,0,65,2,106,16,0,32,1,16,0,107,11,11,146,128,128,128,0,1,0,65,12,11,12,1,0,0,0,0,0,0,0,1,0,0,0]?
Знакомство с WebAssembly