It'd be cool to see it get "security/penetration tested/fuzzed" to see if "just because it's in Rust, is a good hacker able to find anything"
Maestro: A Linux-compatible kernel in Rust
281–290 of 380 posts
Re: Maestro: A Linux-compatible kernel in Rust
#282It'd be cool to see it get "security/penetration tested/fuzzed" to see if "just because it's in Rust, is a good hacker able to find anything"
Rust is not able to shield from everything. On top of that, there is a lot of unsafe code.
I am 100% sure that fuzz-testing or pentests would reveal a lot of issues. This is not something I had time to work on yet.
Re: Maestro: A Linux-compatible kernel in Rust
#283So many thank to all of you for your support! This project has represented a lot of efforts for me and it means a lot! Right now the website seems to be pretty slow/down. There is a lot of traffic, which was not expected. I also suspect there might be a DoS attack going on. I will try to make it work better when I get home! (I am currently at work so I cannot give much attention to it right now) Sorry for the inconve…
DOS from HN's very own Slashdot effect...
For those who are wondering WTF is a Slashdot, and how does it effect websites.
https://tech.slashdot.org/story/24/01/03/0017242/25-years-si...
Re: Maestro: A Linux-compatible kernel in Rust
#284Earlier quoted context omitted.
Drivers are the tough part and the lack of a stable interface in Linux makes them hard to reuse.
There have been attempts to create kernel-agnostic interfaces for drivers such as: https://en.wikipedia.org/wiki/Uniform_Driver_Interface For my case, I am planning to re-implement them. I like doing this. I sure am not going to be able to re-implement everything myself though. I will concentrate on what I need, and I will consider implementing others if anyone else other than me is willing to use the OS (which would…
Or try to adopt Fuchsia/Android model of userspace drivers, maybe there is something to be reusable from them.
Re: Maestro: A Linux-compatible kernel in Rust
#285Earlier quoted context omitted.
Even if this is true, which I agree it is, it’s still a 100x more painful than writing a programming language and compiling to RISC-V. That also gives you the benefit of compiling to multiple arch’s
This is where you are wrong: it will take more time, be a bit more painful and require a different training... but your code will be shielded against compiler and language complexity and planned obsolescence, which has stellar value on the long run. Short term-ists won't understand as this is going for the long run, and that requires perspective of what happened in software in the last decades.
> it will take more time, be a bit more painful and require a different training... but your code will be shielded against compiler and language complexity and planned obsolescence, which has stellar value on the long run.
This is a bit of a stretch. Not one ISA has lived longer than C without making any changes whatsoevever, but I admit that this could at least be possible for some kinds of devices. What is utterly ludicrous is to suggest that people write code only in RISC-V because all hardware ever built in future will somehow agree to only use RISC-V. If any hardware ever uses any other ISA, then we're back where we started, writing in higher-level languages that can compile to multiple ISAs. What do you believe will fundamentally change this?
Anyway, your argument about churn is flawed from a simpler angle anyway. When C, C++, or Rust evolves in future, existing code continues to work. That's the very opposite of "planned obsolescence", it's ensuring that past investment continues to pay future rewards. The ISO working groups and the Rust team go to enormous lengths to ensure code remains compatible while making new advancements. I don't know how much of these processes you've observed in the past, but if you're calling them "planned obsolescence" I would urge you to learn more about them before producing critiques.
An ISA can also continue to evolve in strictly backwards-compatible ways, but history has shown there are many reasons that multiple ISAs can coexist and that newer ones may supersede older ones without backwards compatibility. RISC-V may avoid some of those factors, but as it's barely been adopted in the real world at all yet, it's a bit premature to somehow presume it's the last word on ISAs and no new ISAs should ever be created ever again.
Re: Maestro: A Linux-compatible kernel in Rust
#286Earlier quoted context omitted.
Compare in what way? Handwritten and commented assembly will be much easier for a human to maintain. However modern optimizers are much more likely to apply the correct micro optimization tricks to get the best performance - and they can output different assembly for different variations of the same instruction set with ease, something that would make the hand written assembly much more complex.
"Handwritten and commented assembly will be much easier for a human to maintain" It seems some people here have issue acknowledging that. But where you are wrong: for modern micro-archs, everything mostly happens at runtime. Specific micro-archs optimizations are not done anymore, the linux kernel do not bother anymore and is compiled for "generic" x86_64 for instance, it is not worth it (and may cause more harm in t…
> the linux kernel do not bother anymore and is compiled for "generic" x86_64 for instance, it is not worth it (and may cause more harm in the end)
This is not the reason why. Indeed x86_64 has a much broader instruction & register baseline than i386 did, so the impact of per-CPU tuning is less than it used to be. But even a generic compiled Linux selects CPU instruction sets at runtime for things like hardware-accelerated cryptography, because those instruction sets actually matter. If you have evidence that modern microcode magically recognizes hand-written AES and replaces it with the equivalent AES-NI instructions, please be sure to send Linus your patches with benchmarks.
Re: Maestro: A Linux-compatible kernel in Rust
#287Earlier quoted context omitted.
How would you enforce use of (only) the correct kind of mutex in interrupt context?
You would probably need to pass around a context type that encodes information about the current context and which interrupts are possible. You would then acquire the lock via that context, which would handle disabling those interrupts.
Still need to set the context correctly on entry to your interrupt handlers, I guess, and passing it around is kind of ugly. In C kernels you often stash contexts in CPU-locale variables, maybe you could do something like that instead of passing it around.
Re: Maestro: A Linux-compatible kernel in Rust
#288Syscalls are easy. Drivers will be tough.
Drivers are difficult if you need to support lots of them. If you pick just one or a few pieces of hardware then it should be fairly straightforward. Target VMs only for example and you probably cut away 99% of the driver complexity.
Re: Maestro: A Linux-compatible kernel in Rust
#289Earlier quoted context omitted.
DOS from HN's very own Slashdot effect...
For those who are wondering WTF is a Slashdot, and how does it effect websites. https://tech.slashdot.org/story/24/01/03/0017242/25-years-si... https://en.wikipedia.org/wiki/Slashdot_effect
Slashdot was the GOTO site in the late 90's early 00's for tech news...
Re: Maestro: A Linux-compatible kernel in Rust
#290My two cents-- make the license be exactly whatever Linux is-- gplv2 only IIRC
If you do this then you'll never waste another moment discussing licenses for the rest of your life. It's just "because it's what Linux uses" to the end of time.
And even if there's some future question about license enforcement or whatever wrt gplv2, it will get decided within Linux/Linux Foundation/etc. and you just surf in on whatever happens without a care in the world.
Same with what-ifs about, say, code potentially going back and forth between your project and whatever part of Linux becomes written in Rust. With MIT you'll get GPL zealots and/or MIT trolls chatting your head off about legal things they don't understand. With GPLv2 GPLv2, it all gets optimized out. :)
In any case, MIT 3-clause is a fine license so use that if you have your reasons. But trust me, optimizing out low-effort discussions of software licenses is worth it if you can do it. :)