> A. Drop all efforts at rebuilding UNIX in language X.
... OK, but then you say "full POSIX" later. So how does that differ?
> B. Get a user-mode version of Linux running on it with user-space drivers on microkernel for one, easily-acquired board.
How is this relevant to what happens later? The whole goal is to not rely on the Linux kernel.
> C. Redirect safe language efforts on creating a secure runtime on the microkernel.
There aren't "safe language efforts". There is a safe language that already exists, and the effort has already been expended to make that exist. The project is creating a secure runtime on the microkernel using that safe language.
> D. Create middleware tools along lines of Protocol Buffers, ZeroMQ, or LANGSEC stuff
You mean like serde? This is already done for the Rust ecosystem.
> E. Begin on a POSIX-like runtime whose components can be stripped on a case-by-case basis. Focus on syscalls used by critical libraries and services first.
How is this not what this project is doing?
> F. The current goal of full POSIX. 99% dont make it to E. If they get here, then great. If to E, then we get at least some apps. If to C and D, then we at least have trustworthy runtime.
... in other words, exactly what the project is doing?
You did notice how I went from an extremely hard task (full POSIX) to a series of them that gradually deliver more and more useful functionality over time if resources and labor permit? First goal is a runtime. Next is key POSIX features (80/20 rule). Next is full POSIX. If you cant do a runtime, you cant do POSIX.
Re B
Linux kernel is a user-mode API that gets you lefacy apps inmediately. You gradually replace the syscalls with your own and eventually get off it. Meanwhile, critical stuff runs outside Linux VM on a Rust runtime directly on microkernel or other trusted components. WAY better than just Linux kernel.
Re C
No, there are dozens of projects trying to make OS'S or runtimes in safe languages. There's closer to 100 that started as learning projects then petered out when hard reality set in. Dead link after dead link. Hence, I said it in plural as my recommendation and gradual progression applies to most. Including a Rust project.
Re D
Im not a Rust user so that's new to me. Good to know they have it. Thanks for tip.
Re E
You addressed that point in isolation. The context is a series of steps with gradual increase of difficulty and intermediate deliverables. Starting at Step 5 is clearly not my recommendation.
Re F
And Step 6 follows Step 5 if author had skill and resources to achieve it. Starting at Step 6, like 5, dramatically increases odds it will be another entry in archive.org rathet than protecting real systems.
More to point, I can name many systems that tool my route to success even on a budget and some resisting NSA pentesting w/ source. Maybe it's ny broken memory but I can't name even one project that implemented POSIX in a safe language clean slate. Hence, my recommendation.
I didn't understand the parent comment either. For what it's worth: this is the first project I've seen that really made me want to start playing with Rust.
It's pretty simple: almost all efforts to duplicate POSIX in a safe language failed. The commercial practice is porting a POSIX or Linux API in C to a virtualized partition that runs on microkernel. Safety-critical apps run either directly on the microkernel or on a minimal, language-specific runtime running directly on kernel. Keeps TCB tiny. Overall app/system is split with untrusted components in POSIX/Linux system & security-critical stuff in the minimal partitions. Unlike safe POSIX, this is a proven model done by many small teams.
In this case, it would be a RTOS or user-mode Linux, plus a custom runtime or target for Rust apps, and IPC/middleware to connect the two. Way easier to build. POSIX comes later if effort comes along.
And for the Rust half, that's exactly what's in our roadmap and introduction :) Robigo (the POSIX environment) is a long-term stretch goal so that I can run my own OS on a RISC-V laptop of my own devising and still run traditional UNIX programs like GNU. I think we're in violent agreement.
Im on mobile and didnt realize you were project head when I first replied. Id have been more helpful. My bad.
Im glad your doing it gradually with intermediates. That will let it benefit spinoff projects or even products hopefully. Plus keep you from getting overloaded.
I also like that RISC-V is in your long-term vision. Keeping that in mind early will help avoid architectural mistakes early on. Id say use the ISA closest to it in meantime so little change is necessary.
Far as overall scheme, I'll email you some reference work if your interested in prior work on safe runtimes, split apps, high-security dev techniques, and so on. Might be able to integrate that into idiomatic Rust. That's your call though.
I'd be very interested in that! I don't have a lot of experience in this area, it's just something I'm interested in and started hacking away at. Email is in my profile.
Nobody said it was same project and it would be orthogonal to others. My claim is redoing POSIX will likely fail while first doing a Rust runtime for seL4 kernel is much easier and straightforward to use. Essentially, like Nizza security architecture or MILS kernels but with Rust for apps that run directly on microkernel.
... OK, but then you say "full POSIX" later. So how does that differ?
> B. Get a user-mode version of Linux running on it with user-space drivers on microkernel for one, easily-acquired board.
How is this relevant to what happens later? The whole goal is to not rely on the Linux kernel.
> C. Redirect safe language efforts on creating a secure runtime on the microkernel.
There aren't "safe language efforts". There is a safe language that already exists, and the effort has already been expended to make that exist. The project is creating a secure runtime on the microkernel using that safe language.
> D. Create middleware tools along lines of Protocol Buffers, ZeroMQ, or LANGSEC stuff
You mean like serde? This is already done for the Rust ecosystem.
> E. Begin on a POSIX-like runtime whose components can be stripped on a case-by-case basis. Focus on syscalls used by critical libraries and services first.
How is this not what this project is doing?
> F. The current goal of full POSIX. 99% dont make it to E. If they get here, then great. If to E, then we get at least some apps. If to C and D, then we at least have trustworthy runtime.
... in other words, exactly what the project is doing?