pizlonator

5 ms·

1.
Just testing my memory safe web browser
2 points by pizlonator 5d ago|1 comments
2.
by pizlonator 11d ago
> easy to be safer It took over two years and help from contributors to get to the point where WebKit could be made fully memory safe.
3.
by pizlonator 11d ago
How would memory safety have not made a difference?
4.
by pizlonator 12d 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 o
5.
by pizlonator 12d 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 wo
6.
by pizlonator 12d 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
7.
by pizlonator 12d ago
Yes I have a new tech called SaRCAsm, which is a memory-safe assembler. So the next step is a "Sarcastic JIT" :-)
8.
by pizlonator 12d ago
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.
9.
by pizlonator 12d ago
Yeah
10.
by pizlonator 12d ago
There's a risk that someone had been sitting on a sandbox escape that assumed having RCE inside the sandbox first, and so they'd been waiting for an RCE exactly like this one. Those folks would not be disclosing their sandbox esca
11.
by pizlonator 12d ago
I think the problem is that we've let JS engines become absurdly complex so there's no way to avoid them having really gross bugs. That said, I think that the V8 team has done a fantastic job of securing their engine. Their heap s
12.
by pizlonator 12d ago
Sounds wild. (Posted from memory safe WebKit; i.e. WebKit compiled with filcc and all of WebKit's dependencies compiled with filcc.)
13.
by pizlonator 17d ago
This doesnt seems to be meaningfully different from Rust. > does not require tracing garbage collection Just call it garbage collection. (Applies in two ways: if you think that garbage collection subsumes reference counting then this lan
14.
by pizlonator 1mo ago
That is a great feature But it’s strictly less safe than either Fil-C or Rust since it only protects bounds
15.
by pizlonator 1mo ago
Correct
16.
by pizlonator 1mo ago
Yeah rlbox is great. Fil-C is more precise than valgrind or asan. Valgrind and asan will allow a buggy access (like an OOB) to succeed if the resulting address is valid at all - which is useless from a security enforcement perspective since
17.
by pizlonator 1mo ago
From the second paragraph of fil-c.org: "Fil-C has no unsafe statement and only limited FFI to unsafe code." `zunsafe_call` is a weird thing to get hung up on as an "escape hatch", considering it's just a super limi
18.
by pizlonator 2mo ago
Genius.
19.
by pizlonator 2mo ago
How do you enforce this?
20.
by pizlonator 2mo ago
I have worked on both a major JS runtime and a .NET runtime. I have fixed hundreds of security bugs in JSC. Based on that, I have no doubt that what Fil-C does is safer. Just the absence of a JIT makes it safer in a way that I don’t think i
21.
by pizlonator 2mo ago
Saying something that you don’t believe isn’t trolling.
22.
by pizlonator 2mo ago
This thread is evidence of it. The OP is about Zig and now there are 40+ mentions of Fil-C initiated mostly by Rust folks and those comments are largely criticizing me personally. That’s toxic AF!
23.
by pizlonator 2mo ago
I never claimed that Fil-C is objectively better than Rust. As a long time PL researcher, I can, should, and will point out interesting corner cases of languages. Including in Fil-C or Rust
24.
by pizlonator 2mo ago
Steve, be reasonable. I never said Fil-C is “so much better” (let alone with all caps) than anything. I never called Rust “trash”. I think you’re taking this all too personally
25.
by pizlonator 2mo ago
This is a simple fact. The Fil-C runtime is tiny compared to TS and C#
26.
by pizlonator 2mo ago
First of all, it’s incredible that on a HN thread about a language that isn’t C, there are 46 mentions of Fil-C! You guys are obsessed! I make bold claims because they hold water. - You can at worst corrupt only the capability you’re pointi
27.
by pizlonator 2mo ago
Yes, being able to build small and fast binaries in TS would be a valuable capability, which is why basically all of us who work in this space have thought of this idea and rejected it after going deep on it. This isn’t a new idea. CanadaHo
28.
by pizlonator 2mo ago
They will have untyped dependencies. That’s how the TS/JS ecosystem works. Note that “untyped dependency” means any code that says `any`.
29.
by pizlonator 2mo ago
Yeah - using quickjs at all in a thing that needs perf. Quickjs is hilariously slow. Midwits use it because it has “quick” in the name. - using floats for numbers and deferring int optimizations for later. Inferring ints is like half the pr
30.
by pizlonator 2mo ago
That explains why: - the architecture is idiotic. - they have zero credible perf numbers. I plan to benchmark it using generally accepted methods. Porffor makes careful trade offs that make sense and is benchmarked in a way that I can belie

More ›