html5 hype

[wizzard0]

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

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

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

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

Comments

[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]

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