Maestro: A Linux-compatible kernel in Rust • Hacker News Board

Re: Maestro: A Linux-compatible kernel in Rust

#331

Post by phkahler » Thu, Jan 04, 2024, 1:02 PM UTC

bigstrat2003 wrote: post #292

phkahler wrote: post #264

Earlier quoted context omitted.

>> The amount of hate for GPL on HN is disturbing. I agree. I'm really baffled by the Rust community pretty much standardizing on MIT license. People laugh at "Rewrite it in Rust" which I think is a good thing but completely ignore the whole "strip users of their freedom" that is coming with it one day.

This FUD always comes up from people who support the GPL and it's so annoying. Let's say that Maestro takes off and gains popularity, and then someone decides to turn it into a commercial OS. What, exactly, is supposed to be so bad about that? Nobody loses a damn thing - if you want to use the MIT licensed original project, it hasn't gone anywhere. And for those who find that there's value in the commercial version,…

Linux has a LOT of paid commercial developers. Imagine those companies closed source and produced a commercial kernel that's way ahead of the open one - because they could and would if the license allowed. The public code couldn't keep up and would be kind of useless.

On the other hand, the scenario you describe where everybody wins is already proven to work with the GPL since that is the Linux story. That is the point of it - when everyone cooperates we all win.

Re: Maestro: A Linux-compatible kernel in Rust

#332

Post by drtgh » Thu, Jan 04, 2024, 3:39 PM UTC

samus wrote: post #312

drtgh wrote: post #266

Earlier quoted context omitted.

Thanks for your comment. SELinux and AppArmour don't do exactly what I commenting, those tools are more or less homologous to create users with different permissions for each application. RSBAC kernel extension would get closer, but not enough. I really consider a need the system I commented, remarking process injections active supervision and internet access control, so I've been searching along one year or so for i…

SELinux precisely allows things like restricting applications to specific ports or specific files though. Pretty sure that it would also be possible to restrict internet access and things like that. What it needs is better UIs. The potential for process injections is severely reduced by design on systems such as Android or when containerizing applications, for example with Flatpak. Modulo kernel bugs or being root, i…

> when containerizing applications, for example with Flatpak. Modulo kernel bugs or being root, it's simply not possible to mess with the processes of another user.

Wrong.

> Advanced desktop users have better things to do than reviewing security warnings all day long. I get paid to write code instead of investigating what my applications are doing.

Oxymoron.

Re: Maestro: A Linux-compatible kernel in Rust

#333

Post by yencabulator » Thu, Jan 04, 2024, 4:06 PM UTC

GuB-42 wrote: post #20

insanitybit wrote: post #6

A memory safe linux kernel would be a fairly incredible thing. If you could snap your fingers and have it, the wins would be huge. 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. The reason why a VM like Firecracker is so much safer is that it removes the kernel as the primary…

More like memory safer. A kernel necessarily has a lot of unsafe parts. See: https://github.com/search?q=repo%3Allenotre%2Fmaestro+unsafe... Rust is not a magic bullet, it just reduces the attack surface by isolating the unsafe parts. Another way to reduce the attack surface would be to use a microkernel architecture, it has a cost though.

Maestro has a lot of very old school hardware drivers: VGA, PS/2, IDE/ATA.

Newer hardware tends to look like just a couple of ringbuffers, and the drivers should need a lot less of these hacks. Here's an NVMe driver in Rust that intends to avoid unsafe fully: https://rust-for-linux.com/nvme-driver

Re: Maestro: A Linux-compatible kernel in Rust

#334

Post by yencabulator » Thu, Jan 04, 2024, 4:17 PM UTC

phkahler wrote: post #331

bigstrat2003 wrote: post #292

Earlier quoted context omitted.

This FUD always comes up from people who support the GPL and it's so annoying. Let's say that Maestro takes off and gains popularity, and then someone decides to turn it into a commercial OS. What, exactly, is supposed to be so bad about that? Nobody loses a damn thing - if you want to use the MIT licensed original project, it hasn't gone anywhere. And for those who find that there's value in the commercial version,…

Linux has a LOT of paid commercial developers. Imagine those companies closed source and produced a commercial kernel that's way ahead of the open one - because they could and would if the license allowed. The public code couldn't keep up and would be kind of useless. On the other hand, the scenario you describe where everybody wins is already proven to work with the GPL since that is the Linux story. That is the poi…

I just don't think this is a huge threat. If there's a viable open source community, detaching your proprietary kernel from it just causes your company to be stuck with an old version, not able to benefit from the larger development community.

There are already plenty of de facto proprietary forks of Linux. Practically every embedded SDK comes with one. Yes they have to publish the source because of the GPL, but they never bother doing that in a form that helps getting any of the work merged into upstream Linux. All those vendor-specific forks end up stuck at some random old kernel with dozens of known issues, effectively abandoned. This has effectively ruined the ARM landscape, and of the end-user visible SBC choices only RPi has a decent reputation for working well enough with upstream Linux devs.

Submitting your changes to upstream Linux is a competitive advantage. (With the trade-off that you can't hide your sooper sekrit hardware designs as well.)

Google/Android has put in a huge amount of effort to drag the hardware vendors out of this pit where they get stuck on old kernel versions...

Re: Maestro: A Linux-compatible kernel in Rust

#335

Post by maayank » Thu, Jan 04, 2024, 4:32 PM UTC

insanitybit wrote: post #70

maayank wrote: post #65

Earlier quoted context omitted.

I’m interested of reading more. Where can I find the blog posts?

https://web.archive.org/web/20221130205026/graplsecurity.com... The company no longer exists so you can find at least some of them mirrored here: https://chompie.rip/Blog+Posts/ The Firecracker, io_uring, and ebpf exploitation posts. Chompie was my employee and was the one who did the exploitation, though I'd like to think I was at least a helpful rubber duck, and I did also decide on which kernel features we would b…

Many thanks, read some and plan on others. Very informative.

Re: Maestro: A Linux-compatible kernel in Rust

#336

Post by steveklabnik » Thu, Jan 04, 2024, 5:00 PM UTC

Anonbrit wrote: post #326

steveklabnik wrote: post #274

Earlier quoted context omitted.

> Clearly you can only do worse in Rust than you'd have with perfect C. Is this clear? Why would the best Rust be worse than the best C?

Rust has a few small but unavoidable runtime overheads compared to the best C (maybe they can be avoided with the right unsafe usage but that removed most of the benefits of rust). They are difficult to see the affect of without micro-benchmarking in my very limited experience, but C can avoid them

I am not saying that Rust is better, but not worse. Saying unsafe Rust doesn't count because it's unsafe but C gets to count feels like an unfair comparison to me: this did start out with assuming perfection on both sides.

Re: Maestro: A Linux-compatible kernel in Rust

#337

Post by RetroTechie » Thu, Jan 04, 2024, 5:12 PM UTC

colonwqbang wrote: post #296

loeg wrote: post #261

Earlier quoted context omitted.

How would you enforce use of (only) the correct kind of mutex in interrupt context?

In Haskell this should be "easy" to do using monads. You would have a process monad and an atomic monad (using Linux terminology). The operation to lock a sleeping mutex would live in the process monad. It would be possible to lift an atomic computation into process context (disabling interrupts) but not the other way around. I don't think rust has such a concept of different computation contexts (does it?) Of course…

> Of course Haskell may not be the most suitable kernel implementation language for other reasons...

seL4 microkernel would like to have a word with you..

Re: Maestro: A Linux-compatible kernel in Rust

#338

Post by toast0 » Thu, Jan 04, 2024, 5:40 PM UTC

PrimeMcFly wrote: post #318

toast0 wrote: post #269

Earlier quoted context omitted.

> What a cool little project. It's astonishing how far this can boot with less than a third of the syscalls of Linux implemented. My hobby OS is more or less a FreeBSD compatible kernel for one specific language VM[1]; it looks like I support 61 syscalls out of 424, and it's been a while since I ran across one I missed (sometimes syscalls are only called in some code paths, or when I target a newer kernel, there may…

Got a github?

Not yet, I've got one more milestone to hit before I make it public, and I'm working on some other things before I tackle that.

Release milestones are SMP, networking, amd64. SMP works! Networking works for realtek gigE and virtio-net! amd64 hasn't been started (runs x86-32 bit) and will be a big task and should touch a lot of the kernel and clean up.

But, I wasn't trying to hijack this thread. Email me.

Re: Maestro: A Linux-compatible kernel in Rust

#339

Post by MisterTea » Thu, Jan 04, 2024, 6:01 PM UTC

jodrellblank wrote: post #307

MisterTea wrote: post #238

Earlier quoted context omitted.

> I don't think I've ever seen an argument for why "everything is a file" is a desirable thing. A file system is a tree of named objects. These objects are seamlessly part of the OS and served by a program or kernel driver called a file server which can then be shared over a network. Security is then handled by file permissions so authentication is native through the system and not bolted on. It fits together very we…

I like the example and the detailed explanation but "it works in some scenarios" is only enough to say that some things work well as files, it's not enough to convince that everything should be a file (or that everything should be the same, whatever the same is). > " sky's the limit, just put the logic in the fs " You can, but why is it better to do that? "just" put the logic in a Python script seems much simpler tha…

> a low level pretend filesystem driver

Plan 9 IS NOT Linux or Unix. It is a pure VFS and only speaks 9p. A plan 9 file server serves a real file system. Think of the file server as an abstraction that closely resembles a micro service. It handles the multiplexing of multiple clients who might want/need to open the same file.

If you have a sign that takes formatted text via RS232 then you don't need the file server or the logic as the sign already handles this. You just need to write text to /dev/eia0 or whatever. Setting the com port settings is done via the com ports control file /dev/eia0ctl. This means you can use a shell script to set the com port settings by echoing the baud and all that into the ctl file.

However, what if you bought an LED panel that was just a bunch of LED's? It doesn't understand text or formatting so now you need to hook it to a CPU and write code. In this case, a file server running on a pi would be a great interface to handle that. The server would contain the logic to accept a formatted string of text and turn that into glowing LED's. Then any program can open that file to operate the display like a script, python program, or web server.

Re: Maestro: A Linux-compatible kernel in Rust

#340

Post by hnfong » Thu, Jan 04, 2024, 6:04 PM UTC

lifthrasiir wrote: post #168

px43 wrote: post #159

Earlier quoted context omitted.

Eh, seL4 has a suite of tools that turn their pile of C and ASM into an obscure intermediate language that has some formally verifiable properties. IMO this is just shifting the compiler problem somewhere else, into a dark corner where no one is looking. I highly doubt that it will ever have a practical use beyond teaching kids in the classroom that formal verification is fun, and maybe nerd-sniping some defense weir…

seL4 actually has an end-to-end proof, which proves that the final compiled binary matches up with the formal specification. There are not many places that bugs can be shifted---probably the largest one at this point is the CPU itself.

The bugs are shifted into the spec, or the proof.