Writing alternatives to GPL software under MIT/Apache licenses is really harmful for the FOSS ecosystem. We need to protect end users from more and more proprietarization, tracking and privacy breaching, SaaS and untrusted IoT devices.
[deleted]
Maestro: A Linux-compatible kernel in Rust
211–220 of 380 posts
Re: Maestro: A Linux-compatible kernel in Rust
#212Tangent, but I love this Gource thing that the author made the contribution video with. I'd never seen it before but had an idea to try making something like it a couple of years back - no original ideas it seems!
On my side, I discovered it a while ago with this video: https://www.youtube.com/watch?v=zRjTyRly5WA
Re: Maestro: A Linux-compatible kernel in Rust
#213I really like the idea of building a kernel, especiallly for learning purposes. Curious about the resources you used to understand the whole kernel/OS thing
Re: Maestro: A Linux-compatible kernel in Rust
#214What a cool little project. It's astonishing how far this can boot with less than a third of the syscalls of Linux implemented. However, my guess is that the ones that are missing are the more complicated ones. The TTY layer, for example, looks rather basic at the moment. Getting this right will probably be a lot of work. So don't hold your breath for Maestro running your Linux applications in the next 3 years or so…
Is there maybe a subset of Linux applications that it could run soon? A proxy, nfs, some database server, http server, firewall? I think it doesn't need to run Steam, libreoffice and Firefox to be useful. Many parts in a common server or microservices architecture are relatively simple in what they do and would probably benefit a lot from a safe, simple kernel.
Indeed, as I stated in the blog post, I am not very far from being able to run a text editor such as Vim or a compiler :)
Re: Maestro: A Linux-compatible kernel in Rust
#215I really like the idea of building a kernel, especiallly for learning purposes. Curious about the resources you used to understand the whole kernel/OS thing
Mostly https://wiki.osdev.org/Main_Page + Wikipedia
Re: Maestro: A Linux-compatible kernel in Rust
#216Earlier quoted context omitted.
Well, I think you are wrong, and that would actually be the real way forward: an assembly written kernel using a worldwide standard ISA, aka RISC-V. Of course, it would have not to abuse any preprocessor, because moving the issue which is the complexity of the compiler dependency to a preprocessor complexity dependency would nullify everything. Doing that in rust, is just doing the mistake of linux all over again, ac…
Are you proposing a kernel that would only run on risc-v hardware, or expecting that people would run some kind of emulator? ....or do you think that because RISC-V is "standard", assembly for RISC-V would run on any hardware?
The "right way" would be CPU vendors to support that standard. But I have thought about running a 64bits RISC-V interpreter on x86_64 (Mr Bellard, ffmpeg, tinycc, etc, wrote a risc-v emulator which could be as a based for that), and that in the kernel. Basically, you would have RISC-V assembly for x86_64 arch: at least, RISC-V here would be stellar more robust and stable that all the features creeps we have in the linux kernel because of the never ending gcc extensions addition and latest ISO C tantrums...
Re: Maestro: A Linux-compatible kernel in Rust
#217Re: Maestro: A Linux-compatible kernel in Rust
#218Earlier quoted context omitted.
> Consider that right now a docker container can't be relied upon to contain arbitrary malware, exactly because the Linux kernel has so many security issues and they're exposed to containers If you don't run docker as root, it's fairly ok for normal software. Kernel memory safety is not the main issue with container escapes. Even with memory safety, you can have logical bugs that result in privilege escalation scenar…
> . Kernel memory safety is not the main issue with container escapes. I disagree, I think it is the primary issue. Logical bugs are far less common. > the Linux kernel isn't exactly trivial to exploit either these days It's not that hard, though of course exploitation hasn't been trivial since the 90s. We did it at least a few times at my company: https://web.archive.org/web/20221130205026/graplsecurity.com... Chomp…
A single talented developer taking weeks sounds about right, that's what I meant by difficult but also you have vulns that never get a cve issued or exploit developed because of kernel specific hardening.
As for container escapes, there are tools like deepce:
https://github.com/stealthcopter/deepce
I can't honestly say I've heard of real life container escapes by attackers or pentesters using kernel exploits. Although I am sure it happens and there are people who won't update the host's kernel to patch it.
Re: Maestro: A Linux-compatible kernel in Rust
#219Sounds like a fun project. Curious though: most of the drawbacks to using C and difficulties with developing an OS are around debugging. I assume that the switch to Rust eliminated a certain class of memory error but is debugging still a pain? Or is there less of it than before the switch making debugging more tolerable?
A lot of memory and concurrency issues have been eliminated. It is still a pain to debug, but a lot less than it was before though. As an example, there is not a lot of chances you forget to use a mutex since the compiler would remind it to you by an error. This is not a silver bullet though, things such as deadlocks are still present. Especially with interruptions. To give an example, if you decide to lock a mutex,…
I suspect those sort of liveness properties (and likely some safety properties in unsafe code) cannot be encoded in Rust's type system and you'd have to use a model checker at some point.
Still, it's cool to see such a system used and providing immediate benefits. Happy hacking!
Re: Maestro: A Linux-compatible kernel in Rust
#220MIT license? If by chance this evolves into something big, it will be eaten alive by commercial interests. Look at the conflict between Linux devs and nVidia for example. Look at the IBM/RedHat stuff trying to circumvent the spirit of the GPL, if maybe not the text of it. If it becomes a thing, the most active developers will be paid by corporations and they will not be sharing code with you when it suits them - whic…
The amount of hate for GPL on HN is disturbing.