Comment by DaveParkCity
2 days ago
I'm in the (near) memory safety absolutionist camp.
Fil-C is an amazing technology, and we should use it, but we should also recognize its limitations.
An as-written JIT or GC can not be compiled with Fil-C because they are inherently memory unsafe.. which means one of the biggest user CVE targets by volune, Google Chrome, not only can not be compiled by Fil-C -- it also can't consume Fil-C compiled libraries. (Chrome not only has v8 jit, but 2 different GC systems - V8's and Oilpan, plus PartitionAlloc)
Which means Fil-C is an amazing tech for securing the manual-deallocator daemons and backends, but does not secure the biggest attack vector on 2 billion consumer devices.
This is why i'm writing a maximally memory safe browser in dotnet where the only unsafe will be the FFI and RyuJIT underneath me. [1]
I also think we have gone too long with poor operating system safety tools. I want a system based on Andrew Valencia's VSTa's hierarchial capability system. In that system protection ids are hierarchial and infinitelly narrowable without any special authority. So user.david can forge user.david.browser which can forge user.david.browser.site.ycombinator and so on. The closest we have to this today is (relatively) heavy weight virutlized containers.
absolutionist => absolutist