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

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

VM

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

Sweet, thanks. I guess running in a VM is also a bonus protective layer:)

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

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?

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.

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

Yeah

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

I think it makes more sense to verify that the jit is correct than to verify that it's output is correct at runtime.

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

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 :)

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?

Yes

I have a new tech called SaRCAsm, which is a memory-safe assembler. So the next step is a "Sarcastic JIT" :-)