How does Google NativeClient (NaCl) work on x86_64?

Question

Google Chrome

NativeClient technology creates a sandbox for x86 code within a process, while only a small portion of the process's address space is available to code in the sandbox. It is done this way: before starting the module is disassembled and the validator checks that a "safe" subset of instructions is used. The limitation of the available address space is implemented using x86 segment registers. There is no way to escape from the sandbox: instructions that modify segment registers will not pass the validator.
This is a highly simplified description. You also need to achieve an unambiguous interpretation of x86 instructions - due to the fact that instructions have different sizes, it is possible that the code jumps to the middle of the instruction and the bytes from the middle of the instruction are decoded into another valid instruction (which the validator overlooked). Decisionis in the original article.
So I don’t know how it is on Arm, but on x86_64 there is no support for segment registers and there is simply no other similar mechanism. How does it work on x86_64?
The only solution that comes to my mind is to translate each memory access to a dynamically calculated address into a special sequence of instructions that ends with applying a mask to the address (and enforcing this policy in the validator). If this is actually the case, then NaCl should cleanly merge the same java with JIT compilation.

Answer 1

As it turned out, it was enough to look more carefully to find additional materials. I suspected so, but the question was created rather in order to connect with people with similar interests :)
This article describes the solution for x86_64 and arm. Indeed, a special sequence of instructions is used if memory needs to be modified. The slowdown is said to be within 10%. You can read uncontrollably from anywhere, they say that it is safe, because. cookies and other interesting things are managed in another process. IMHO this is not entirely true - at least it can be used to identify the client (you can get a lot of data about his system). pnacl
is described here. Instead of distributing x86, x86_64 and arm code separately, an intermediate bytecode (based on LLVM) is offered.
On the client, this is translated into native architecture assembler and executed in the NaCl sandbox. This is much easier to implement than JIT and has reasonable efficiency.