Hacker News Reader

Comment by hedora | Hacker News Reader

> The idea that running code on the hardware is itself an unsafe operation

Ignoring microcontrollers, and tiny embedded stuff, no hardware or modern operating systems I know of works that way.

Modern hardware almost all has an MMU (which blocks I/O once the process table is set up), and most have an IOMMU (which partitions the hardware mutually distrusting operating systems can run directly on the same machine).

The remaining architectural holes are side channel / timing attacks that hit JS just as hard as bare metal.

View on HN

Process isolation only works across processes. You can't just execute an untrusted block of code without setting up a whole sandbox for it.

Okay, so let's say you have this untrusted block of code:

    L0:
        move    r0, #0
        move    r1, #0
        load.w  r2, [r0]
        add     r1, r1, r2
        store.w [r0], #0
        add     r0, #wordSize
        bz      r0, #0, L0
        move    r0, 42
        ret

which tries to calculate a silly hash of all the memory it can reach via indirect loads and then to zero whatever memory it can reach via indirect stores (which is usually just the whole of the process's memory on modern systems in both cases). What mechanisms do you propose that would allow one to blindly run this code without erasing all kinds of precious information in the memory, ideally still returning 42 in r0 to the caller in the end but without leaking any sensitive information via r1?

CHERI

Quite lapidary.

But enlightening: I did not previously know that CHERI had explicit tool (CCall) to implement the unspoofable "restore privileges and return from subroutine" instruction.

Reply on news.ycombinator.com