5 ms·

Sounds wild. (Posted from memory safe WebKit; i.e. WebKit compiled with filcc and all of WebKit's dependencies compiled with filcc.)

krackers 29d ago
For it to be memory safe, do you have to disable the JIT?
- pizlonator 29d ago
  Yeah
  - amluto 29d ago
    It sounds technically possible to build a JIT where a verifier checks that the JIT-generated code is correctly pizlonated before allowing it to become executable. :)
    - pizlonator 29d ago
      Yes I have a new tech called SaRCAsm, which is a memory-safe assembler. So the next step is a "Sarcastic JIT" :-)
    - Ohentis 29d ago
      I think it makes more sense to verify that the jit is correct than to verify that it's output is correct at runtime.
      - pizlonator 29d ago
        Nah It's damn near impossible to verify that the JIT is correct. But it is possible to verify at runtime that the code that the JIT emitted obeys some memory safety law. (V8's heap sandbox is an example of this; a sarcastic JIT would be an arguably stronger example of this.)
        Ohentis 28d ago
        If you have a runtime check of some correctness, why can't you just prove that the output of your compiler always passes that check?
        amluto 28d ago
        One might argue that verifying the correctness of a JIT is basically the same problem as verifying the correctness of an entire compiler, with the added caveat that malicious inputs to the JIT are expected whereas malicious inputs to a compiler might be seen as rare. IIRC rustc still has a couple of known soundness bugs, for example. It’s only been a few weeks since someone managed to exploit Lean, and Lean is all about formalizing things :)
yjftsjthsd-h 29d ago
Wait, you have that working? What's the lowest friction to run it? Like, VM or docker container or...
- pizlonator 29d ago
  VM https://fil-c.org/pizlix https://fil-c.org/pizlix Then build WebKit using do_cmake_yolo_simpler.sh in projects/webkitgtk-2.44.3 It's still pretty rough, but works more than well enough to post on HN. My regression test is to post on X. That works too
  - yjftsjthsd-h 29d ago
    Sweet, thanks. I guess running in a VM is also a bonus protective layer:)
    - pizlonator 29d ago
      lol yeah Pls file bugs if you encounter issues. Also, fair warning, it's hella slow right now on JS-heavy websites (like X). It barely works. But we can fix that with some effort, I think
achierius 29d ago
Is that just the MiniBrowser?! I have to say I can't imagine daily driving that if so. Why WebKit over a Chromium-based (and more featureful) browser?
- pizlonator 29d ago
  I'll port Epiphany eventually. WebKit's JS engine (JavaScriptCore) is super friendly to pointer capabilities. I did not have to change much to make it use the Fil-C GC instead of its own GC and to make it use a capability per JS object. On the other hand, Chromium's JS engine (V8) does a bunch of crazy stuff with pointer encoding, so the best you could do there is probably a single arena for the whole JS heap. Also, JavaScriptCore has a well-supported mode that involves not only zero JIT but a fully portable C++ interpreter. Not sure V8 has that.
kllrnohj 28d ago
Which wouldn't have actually done anything about this bug fwiw since this wasn't a memory safety issue with any C/C++ code itself

krackers 29d ago

For it to be memory safe, do you have to disable the JIT?

pizlonator 29d ago
Yeah
- amluto 29d ago
  It sounds technically possible to build a JIT where a verifier checks that the JIT-generated code is correctly pizlonated before allowing it to become executable. :)
  - pizlonator 29d ago
    Yes I have a new tech called SaRCAsm, which is a memory-safe assembler. So the next step is a "Sarcastic JIT" :-)
  - Ohentis 29d ago
    I think it makes more sense to verify that the jit is correct than to verify that it's output is correct at runtime.
    - pizlonator 29d ago
      Nah It's damn near impossible to verify that the JIT is correct. But it is possible to verify at runtime that the code that the JIT emitted obeys some memory safety law. (V8's heap sandbox is an example of this; a sarcastic JIT would be an arguably stronger example of this.)
      - Ohentis 28d ago
        If you have a runtime check of some correctness, why can't you just prove that the output of your compiler always passes that check?
      - amluto 28d ago
        One might argue that verifying the correctness of a JIT is basically the same problem as verifying the correctness of an entire compiler, with the added caveat that malicious inputs to the JIT are expected whereas malicious inputs to a compiler might be seen as rare. IIRC rustc still has a couple of known soundness bugs, for example. It’s only been a few weeks since someone managed to exploit Lean, and Lean is all about formalizing things :)

yjftsjthsd-h 29d ago

Wait, you have that working? What's the lowest friction to run it? Like, VM or docker container or...

pizlonator 29d ago
VM https://fil-c.org/pizlix https://fil-c.org/pizlix Then build WebKit using do_cmake_yolo_simpler.sh in projects/webkitgtk-2.44.3 It's still pretty rough, but works more than well enough to post on HN. My regression test is to post on X. That works too
- yjftsjthsd-h 29d ago
  Sweet, thanks. I guess running in a VM is also a bonus protective layer:)
  - pizlonator 29d ago
    lol yeah Pls file bugs if you encounter issues. Also, fair warning, it's hella slow right now on JS-heavy websites (like X). It barely works. But we can fix that with some effort, I think

achierius 29d ago

Is that just the MiniBrowser?! I have to say I can't imagine daily driving that if so. Why WebKit over a Chromium-based (and more featureful) browser?

pizlonator 29d ago
I'll port Epiphany eventually. WebKit's JS engine (JavaScriptCore) is super friendly to pointer capabilities. I did not have to change much to make it use the Fil-C GC instead of its own GC and to make it use a capability per JS object. On the other hand, Chromium's JS engine (V8) does a bunch of crazy stuff with pointer encoding, so the best you could do there is probably a single arena for the whole JS heap. Also, JavaScriptCore has a well-supported mode that involves not only zero JIT but a fully portable C++ interpreter. Not sure V8 has that.

kllrnohj 28d ago

Which wouldn't have actually done anything about this bug fwiw since this wasn't a memory safety issue with any C/C++ code itself