I want to know if a canister can be processed in a sandbox, the canister was processed by only one node in a subnet or all the nodes in the subnet. And if only one node run the canister, can the security be encsured?
Replication will remain the same as before, so an update message of a canister will be processed by all nodes in the subnet. What is changing is that each node gets a sandbox process per canister in order to isolate the canister from the system and other canisters on that node.
Sorry if this was already answered, but I didn’t see it explicitly specified in the original proposal: is the sandboxing something that will be unilaterally applied to all canisters on the IC, or is this an additional feature that will be available to specific canisters/subnets?
Sandboxing will be applied unilaterally to all canisters on each subnet, once the feature is launched on a subnet. The purpose of sandboxing is to protect the IC and other canisters “from” a sandboxed canister, but its own sandbox awards no protection to the sandboxed canister by itself. Hence, it makes no sense for canisters to “opt in” to sandboxing, it only makes sense to treat all equally.
Sandbox is now fully switched to the shared memory representation.
Stable memory operations are handled within the sandbox process without IPC.
System calls that return static data such as (canister_id, controller, and canister_state) are also handled within the sandbox process without IPC.
The SubnetAvailableMemory counter is now maintained properly.
The existing performance optimization to avoid tracking dirty pages for queries is ported to sandbox.
Now the unittests automatically rebuild the sandbox binary if there were wany changes.
A lot of investigation and debugging work was done on the infrastructure side to identify issues blocking CI with sandboxing.
Preliminary benchmarking shows that the performance of sandboxed query calls is on par with the non-sandboxed version. Performance of update calls in memory-intensive workloads has improved by 100x compared to the state two weeks ago, but it is still 2x slower compared to the non-sandboxed version. We are currently experimenting with the optimization that should bring the performance gap down to 20%-30%.
Fix numerous infrastructure issues to enable CI with sandboxing.
Enable sandboxing in ic-replay that is used for disaster recovery.
Implement the performance optimization for memory-intensive updates calls (mentioned above).
Port WasmExecutor::create_execution_state to sandbox so that module instantiation happens in the sandbox process.
Improve error logging and metrics reporting in the sandbox process.
The sandbox process crashed on a single node on pjljw and we had to disable sandboxing there. The investigation is in progress. Until we have a fix we will keep sandboxing disabled on pjljw, eq6en , tdb26.