Как браузер защищает память процесса от скомпилированного кода веб-сборки? - PullRequest
2 голосов
/ 08 июля 2019

Согласно исследованию «Анализ производительности WebAssembly и Native Code», код веб-сборки компилируется в нативные инструкции x86 в Chrome. Насколько я понял, можно создать код WS, который будет обращаться к случайной памяти по случайному адресу. Конечно, будет segfault, если WA попытается получить доступ к памяти, которая не принадлежит процессу. Но в то же время JS и WA работают в одном и том же процессе, не так ли? Как Chrome защищает память Javascript от веб-сборки? Что если код WS обнаружит диапазон адресов для внутренних структур JS и изменит его?

Ответы [ 2 ]

1 голос
/ 08 июля 2019

Код Wasm не может напрямую обращаться к физической памяти ни внутри самого движка Wasm, ни где-либо еще в процессе.Он может получить доступ к памяти только в пределах объявленного массива «линейной памяти», что похоже на доступ к массиву больших байтов.

За пределами доступа к этому массиву не возникает ошибка сегмента.Вместо этого выполнение Wasm будет прервано с так называемой ловушкой, своего рода исключением на уровне Wasm.Двигатели могут реализовывать проверки границ любым удобным для них способом.На 32-битных архитектурах это обычно сравнение реальных адресов.На 64-битных архитектурах движки могут использовать более эффективные методы виртуальной памяти, которые вызывают аппаратный сигнал, который затем ловит движок и преобразует его в ловушку.Однако аппаратная ошибка в этом случае является деталью реализации и не наблюдается кодом Wasm.

1 голос
/ 08 июля 2019

WebAssembly не может напрямую обращаться к какой-либо памяти процесса, скорее, ему разрешено только чтение / запись по адресам памяти в пределах заранее определенной «линейной памяти», которую модули веб-сборки совместно используют со своим хостом JavaScript.

Так что нет, WebAssembly не может получить доступ к случайной памяти по случайному адресу.

...