3 ms·

Without speaking to all of the issues, this is all made much harder by the underlying hardware having extremely bad defaults. The idea that running code on the

Without speaking to all of the issues, this is all made much harder by the underlying hardware having extremely bad defaults. The idea that running code on the hardware is itself an unsafe operation means that any time you want to touch it you need proxies and intermediate languages and all this by default. It's pretty easy for me to imagine a world where running code was safe by default, and this followed all the way to the top. It's obviously not that onerous, else JavaScript wouldn't be as successful as it is. Most of the details the post touches on are then just package management and grouping concerns.

hedora 1y ago
> 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.
- Veedrac 1y ago
  Process isolation only works across processes. You can't just execute an untrusted block of code without setting up a whole sandbox for it.
  - Joker_vD 1y ago
    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?
    - fanf2 1y ago
      CHERI
      - Joker_vD 1y ago
        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.

hedora 1y ago

> 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.

Veedrac 1y ago
Process isolation only works across processes. You can't just execute an untrusted block of code without setting up a whole sandbox for it.
- Joker_vD 1y ago
  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?
  - fanf2 1y ago
    CHERI
    - Joker_vD 1y ago
      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.