html5 hype

[wizzard0]

Интелу надо сделать процессор, оптимизированный для Javascript.

Или сделать свой JS-движок, вложив туда наследие от своего С++-компилятора ;)

Тогда x86 начнут снова любить ;)

This entry was originally posted at http://wizzard.dreamwidth.org/306125.html. It has

Comments

[osdm]

И как бы они могли оптимизироваться под JS? И зачем им писать еще один JS-движок, если есть JITовый V8 от Google? И почему бы всему миру не перейти на Asm.js?

[wizzard0]

> если есть JITовый V8 от Google

Ну, они могли бы начать контрибьютить в х86/х64 джит для v8

> оптимизироваться под JS

всегда есть какие-то паттерны, например, member lookup или еще ченить такое, в проце ведь дохрена эвристик, их можно по-разному тюнить

> почему бы всему миру не перейти на Asm.js?

потому что он хуевый. хотя PNaCl еще хуже ;). msil относительно хороший байткод, но местами слишком высокоуровневый (точнее, я очень хорошего мнения о CLR но местами плохого мнения о BCL)

для веба нужен верифицируемый легковесный байткод какой-то. а верифицируемых байткодов раз-два и обчелся((

[avnik]

LLVM IR как я догадываюсь неверифицируемый?

[wizzard0]

насколько я его смотрел - нет. даже jvm байткод не верифицируемый.

под верифицируемостью подразумевается возможность взять кусок кода и, не запуская его, определить, подходит ли он под security constraints или нет.

[sorcerer_]

> не запуская его, определить, подходит ли он под security constraints

А чем pnacl (или nacl) не подходит-то?

[wizzard0]

тем, что state machine современных x86 cpu слишком сложна для осмысленной верификации по ней

[sorcerer_]

А если на практике? nacl достаточно ок.
Верифицируется - только в путь.
Даже почти без сайд-эффектов.

[wizzard0]

эксплоиты на их верификатор я видел. например, http://www.osvdb.org/show/osvdb/79288
а статей с хотя бы намеками на математическую модель - нет.

почему? ну хотя бы потому, что она сложнее, чем кажется (даже отдельно взятая логика обработки page fault'ов - УЖЕ тьюринг-полная), разные процессоры ведут себя по-разному, а спецификации на них ни Intel, ни AMD не публикуют.

еще держать по верификатору на платформу (x86, x64, arm, arm64, mips) - это как-то тупо, как минимум, это в 5 раз больше багов, чем верифицировать до JIT-компиляции

ну и "достаточно ок" с точки зрения секьюрити не канает, посмотреть хотя бы на ту же Джаву, которая на порядок проще х86, но кроссплатформенные эксплоиты выходят чуть ли не раз в неделю...

[sorcerer_]

> а статей с хотя бы намеками на математическую модель - нет.

S. McCamant and G. Morrisett. Efficient, verifiable binary
sandboxing for a CISC architecture. Technical Report MIT-
CSAIL-TR-2005-030, 2005.

S. McCamant and G. Morrisett. Evaluating SFI for a CISC
architecture. In
15th USENIX Security Symposium
, August
2006.

Ну и вообще в research papers по Nacl все есть.

> эксплоиты на их верификатор я видел

Дык это не то, динамический код действительно не может быть эффективно верифицирован.
Только нахера он, если мы про Сишечку в браузере? :)

[wizzard0]

> Efficient, verifiable binary sandboxing for a CISC architecture

[sorcerer_]

> Пример: VMWare, до того, как нагрянули гипервизоры, наглядно продемонстрировала, что верифицировать или огораживать привилегированные инструкции *медленнее*, чем эмулировать (на интерпретаторе)

Дык накл ничего и не огораживает, а тупо запрещает все, что не разрешено.

> А если интерпретируется байткод с известными свойствами, или *по этим свойствам* генерируется нативный код

Накл тупо берет сабсет х86 и называет его "байткодом". Разницы - никакой, кроме скорости исполнения (все таки нейтив).

> либо в браузере будет *еще в 10 раз больше* процессов (+весь прилагающийся оверхед по CPU/RAM/lock contention на IPC)

Т.е. мы приходим к тому, что все современные ОС - говно полное и процессы не защищены друг от друга, хотя так должно быть.
И теперь мы придумаем красивую абстракцию "байткод" чтобы сверху натянуть ее на овер 9000 уровней иерархии: нод -> процесс -> таск -> тред.
Может просще все таки починить один уровань один раз, например тот же "процесс" с помощью накла и никогда другие уровни не трогать? :)

[wizzard0]

> тупо запрещает все, что не разрешено

[wizzard0]

asm.js как и джава верифицируемые в смысле отсутствия поинтеров, но неверифицируемые в смысле что невозможно четко энфорсить границы привилегий между разными кусками js-кода которые могут получать друг на друга референсы, из-за чего мы имеем pwn2own на котором народ регулярно выигрывает прикольные железки.

в CLR тоже находили ряд дырок, но это implementation bugs а не design bugs, т.е. если подвергнуть формальному анализу фактический код, а не только модель интерпретатора байткода то можно построить весьма устройчивую систему. как результат, их там буквально единицы, тогда как ту же джаву дырявят каждый месяц, там уже вроде трехзначное число кроссплатформенных privilege escalation дырок (т.е. допускаемых моделью)

[109]

+1: я тоже за msil в качестве браузерного байткода.

[w00dy]

линупсоиды изойдут в говно. Продажи попкорна будут бить мировые рекорды :)

[109]

да при чём здесь. есть байткод лучше msil? давайте его использовать.