Поиграл немного с Google Native Client — это плагин для браузера (поддерживаются Firefox, «Опера», «Сафари» и «Хром» и платформы Windows, Mac и Linux на x86, x86-64 и ARM).

Это плагин, который умеет исполнять скомпилированный бинарный (!) код в браузере. В каком-то смысле это напоминает ActiveX. Вы пишете бинарный код, компилируете его в специальной версии gcc, а потом просто встраиваете в браузер тегом EMBED.

Меня интересовало как тут соблюдается безопасность. Коду многое запрещено (по сути, всё, что разрешено — это эффективное использование процессорного времени, за остальным нужно обращаться в браузер через NPAPI или SRPC (Simple RPC)), но разработчики много говорят о том, что допускаются ассемблерные вставки.

Как так?

Ларчик, как оказывается, открывается просто и достаточно остроумно. Во-первых, разработчику запрещается использовать некоторые конструкции, например INT (вызов прерывания) и некоторые другие. Во-вторых, команды переходов модифицированы и это самое интересное.

Не знаю как там в процессорах ARM, а в x86 команды могут иметь разную длину, какая-нибудь «PUSH AX» занимает байт, «MOV AL,41» — два, « MOV AX,[BP+8]» — три и так далее. Если сделать переход не на первый байт команды (а, например, на второй байт команды «MOV AL, 41»), то окажется, что оставшаяся последовательность (возможно с байтами, которые идут дальше) тоже что-то означает (в случае «MOV AL, 41» второй байт будет «41», это команда «INC CX»).

Это даёт возможность замаскировать внутри команды любую запрещённую команду и выполнить её, сделав переход не на первый байт. Как Google Native Client защищает нас от этого? Очень просто.

В Ассемблере есть специальная команда — «NOP» (в x86 занимает один байт, её код — «90»), она не делает ничего. Все команды вашей программы выравниваются до 16 байт этой командой. То есть «MOV AL,41» будет дополнена 14-ю командами «NOP», а все переходы разрешаются только на границу этих 16-ти байт. Для этого у адреса перехода всегда отрезаются несколько младших бит.

Вторая опасность — код в данных, ведь почти любые последовательности байт это какой-то машинный код, таким образом можно запросто спрятать код внутри текста, а потом выполнить переход на этот текст. Понятно, что обладая возможностью ограничить переходы, эту проблему решить несложно — разносим код и данные на разные регистры сегментов и не даём коду переходить на данные. Тут ничего сложного, первый случай был интереснее.

Интересно, что код, контролирующий безопасность и реализующий SRPC, получился очень небольшой, в ролике на YouTube разработчик говорит то о 6000 строк, то о 6000 байт. В любом случае, то и другое — немного. Там же (в ролике) показывали интерпретатор Ruby, работающий в браузере. Это интересно, но не более, интереснее то, что код на Си (или там C++, неважно) пришлось менять очень мало, чтобы перекомпилировать его в Google Native Code.

Мне кажется, это интересный проект.