Return to the Source
cipht.netOne of the greatest strengths of the Web platform is "view source," the ability to start diving into the code any time you find yourself wondering "how did they achieve that?" So a major criticism of WASM is the erosion of that tradition.
However, I suspect that, by volume, most of the WASM code out there is going to be built from open source components, with a little customization sprinkled on top. It takes a little more detective work to find these sources and read them, but I think it's just as worthwhile as in the plain HTML days. Perhaps we could converge on tools and practices that would make it easier to discover the sources from which WASM artifacts were built.
After actually reading the article, my first thought was how awesome of the open source movement to actively promote enabling opportunities to learn by reading code, and how sad that various licenses (and unfortunately even incompatibilities between various open source licenses) and fear of patents restrict those same opportunities.
SRE consultant here.
I was dissatisfied with Linux and FreeBSD, seL4 seems much more robust, in terms of system reliability and security. (seL4 is not an OS, but a framework to build an OS on top.)
Then I was dissatisfied with all the crap in the x86 ISA (bucket of modes, 4 rings, many deprecated features, insecure SMM and zillions of feature flags), the mostly failures of RISC and the over complexity of many versions and variants of ARM (but it’s nice that it’s available as IP).
It seems there ought to be an architecture that can make writing OSes easier and more secure:
- handle task/context switching much faster than x86
- IPC (zero-copy both register and page borrowing, maybe copy if source page is locked or if async.) This enables L4-fast CSP in the ISA.
- resource limits / counters
- memory page allocation
- capabilities management
- transparent page compression and encryption
- OS bookkeeping (kernel-specified privileged data: per task/core/etc.)
in addition to the usual suspects (MMU, FPU, SIMD, etc.):
- virtual memory
- paging (including possible unprivileged page-fault handler)
- hypervisor (VM lifecycle)
- interrupts / faults / exceptions
- TLB
- tiers of caches / cache coherency protocol
- memory controller
- standard I/O controllers
- clock throttling w/ spread-spectrum and thermal management
- micropower standby
- JTAG
- at least one system-wide atomic operation (compare&swap or ainc/adec)
much more rigidly, faster and less clunkily that most OS gunk tends to be. Not CISC overload, but healthy facilitation of fast AND secure OS and user-mode program constructs that are batteries-included.
Also, SystemVerilog looks doable (I’m reading the whole IEEE spec for SV2012) and there’s always MOSIS should a Kickstarter be in order to make actual ASIC dev kits. EDA looks manageable but there’s a definite learning curve to testing, verification, behavioral design, RTL and DRC.
Plus, opaque firmware blobs and chips aren’t conducive to trusting the end-to-end security of the supply chain of a finished product. End customers are almost praying that some fab hasn’t slipped in malicious microcode or RTL changes or the parts stuffers didn’t insert a backdoor into unsecured firmware.
You must be astroturfing (or whatever it's called - submarining, secretly shilling, etc.) for the Mill project[0]! ;)
Every once in a blue moon someone from that group returns from "investing sweat equity into patents" (or however they're [not] getting paid for whatever they're doing) to HN's reality distortion field (welcome!) and blesses us with wisdom[1] from their awe-inspiring project currently classified as vaporware by many such as myself with no public evidence of even a single physical hardware prototype.
I would be interested to hear your thoughts about that project, and also hope my playful jab (not too harsh?) can provoke any of them to respond to your comments (maybe they should hire you!). There are other projects mentioned in those comments that you may find interesting as well (CheriBSD, L4 Linux, etc.)
Also, any thoughts you have time to share on the adaptability of the various open hardware RISCV projects, which seem to be at the beginning stages of delivering just beyond basic functionality without much priority allocated for your secure performance concerns. I was surprised to see no specific mention of it in your initial comment.
To the best of my very limited knowledge, a genuinely secure processor, even versus nation-state level actors, is unfortunately still non-existent or near uselessly underperformant (is that a word?) at this point. Not to mention all of the various other, often easily side-channel attacked, bits and pieces are required to have a working computer!
Perhaps an introduction is already behind you but this is a helpful recent discussion for anyone developing an interest in this aspect of information security: Ask HN: Where do I get started on ASICs, FPGA, RTL, Verilog et. al? | https://news.ycombinator.com/item?id=15379418
PS. Paging HN user nickpsecurity[2] once they wake up since this topic is pretty much their personal hobby horse here. Your comment seems like it was posted by this user a few years ago in an alternate universe, which I mention as a nice way of documenting the very unique similarities of your level of concern.
[0] https://millcomputing.com/
[1] https://hn.algolia.com/?query=%22mill%20project%22&sort=byDa...
[2] https://hn.algolia.com/?query=user:nickpsecurity%20hardware&...
- specifically, on real-world implementations of secure systems https://news.ycombinator.com/item?id=9628845 | https://news.ycombinator.com/item?id=14692557 | etc.
- bonus: on web browsing https://news.ycombinator.com/item?id=9962444