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 inconvenience, but glad you appreciate the project!

https://tech.slashdot.org/story/24/01/03/0017242/25-years-si...

https://en.wikipedia.org/wiki/Slashdot_effect

I have learned to avoid such remarks, unless surrounded by 40y+ folks.

I'm jealous you were able to make time to get this far!

The navbar takes like 33% screen state and can't be removed.

I never understand why people want to make them sticky and steal valuable reading screen space. You can, if you want, always scroll to the top in like 300 ms.

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 (even without taking into account all the thousands of drivers that Linux has)

It's a great project, but I don't find this ratio surprising at all. Any mature platform builds up logic to enable scenarios such that most things don't need most of the system. As the saying goes, no one uses more than 10% of Excel, but it's a different 10% for everyone.

You could implement 30% of Excel functions and probably have an engine which opens 99% of spreadsheets out there.....though if you wanted full doc compatibility you would still have a long journey ahead of you.

Isn't this what effectively googles docs did? For a ton of use-cases google sheets is enough, I've heard of companies that basically were extra stringent about excel licenses (as a cost cutting measure no doubt), instead heavily pushing users toward using google sheets instead.

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 be newer syscalls)

There are a lot of syscalls, and some of them are pretty esoteric; eventually a fully openended replacement will get to most of them, but a third is a good start.

[1] I wanted VM on metal and/or boot to VM, and it became apparent that this is the least effort way to get there, other than probably just having init=/path/to/the/vm; but that doesn't get me what I really want (hardware drivers and tcp stack in the VM language).

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.

You first need to port drivers for your -specific- network and io chipset. And if you want adoption and performance you also need the manufacturer on board. My guess is not quite soon.

[1] https://news.ycombinator.com/item?id=28986229

https://www.redox-os.org/news/development-priorities-2023-09...

The System76 blog appears to have updates regarding COSMIC DE: https://blog.system76.com/post/the-spirit-of-cosmic-december...

Components of Cosmic Desktop Rust-based Desktop Environment: https://github.com/pop-os/cosmic-epoch#components-of-cosmic-...

cosmic-comp/src/wayland/handlers https://github.com/pop-os/cosmic-comp/tree/master_jammy/src/...

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?

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, then an interruption happens, the code that locks the mutex will stop running until the interruption is over. If the interruption itself tries to lock the same mutex, then you have a deadlock, and the typing system cannot help you with this kind of problem.

The solution is to disable interruptions handling while the mutex is locked, but the compiler cannot enforce it.

I don't think rust has such a concept of different computation contexts (does it?)

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

Still, it's cool to see such a system used and providing immediate benefits. Happy hacking!

Please try to keep this mindset.

For running on bare iron.. I suppose there's no short-term solution for that.

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 be incredible if it happened)

https://github.com/rumpkernel/wiki

I clearly understand nothing of this, but it always felt confused about it. Why won't Linux aim for ABI stability? Wouldn't that be a win for everyone involved?

(all of your questions answered and then some)

https://github.com/torvalds/linux/blob/master/Documentation/...

See Windows or android GKI for existence proof that it can be done if so motivated.

So the Linux devs are really against it both from a lack of resources point of view, and from an ideological "we hate closed source" point of view.

Unfortunately, most vendors with closed source drivers don't give a shit about ideology and simply provide binaries for very specific Linux releases. That means users end up getting screwed because they are stuck on those old Linux versions and can't upgrade.

The Linux devs have this strange idea that vendors will see this situation as bad and decide that the best option is to open source their code, but that never happens. Even Google couldn't get them to do that. This is one of the main reasons that Android OS updates are not easy and universal.

(Just bs'ing here, haven't written drivers in over a decade. What other complexity am I missing?)

https://news.ycombinator.com/item?id=38853047

This does not bode well for computers.

However, a part of me is feeling like it could make sense to do a big refactor to turn all of this into a micro kernel. However I am not willing to do this until I have a plan to make it right.

By the way, the 32 bits thing too was imposed by the school. I am now wondering if it still relevant to support it and just support 64 bits only...

On one end device drivers in Rust are now possible, OTOH the Meastro kernel. I wonder if there come be a day in my life that I run a non-C-kernel in prod/ on dev laptop.

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 security boundary.

Imagine if containers were actually vm-level safe? The performance and operational simplicity of a container with the security of a VM.

I'm not saying this is practical, at this point the C version of Linux is here to stay for quite a while and I think, if anything, Fuschia is the most likely successor (and is unlikely to give us the memory safety that a Rust kernel would). But damn, if Linux had been built with safety in mind security would be a lot simpler. Being able to trust the kernel would be so nice.

edit: OK OK. Yeesh. I meant this to be a hypothetical, I got annoyed at so many of the replies, and this has spiraled. I'm signing off.

I apologize if I was rude! Not a fun start to the morning.

Even just considering Linux security itself: there are so, so many ways OS security can break besides a slight (you’re going to have to use unsafe a whole lot) increase in memory safety

It is almost impossible to prove a program is "correct". But things like memory safe languages, static typing, and automated tests allow us to prove the ways in which it is not "incorrect". And the more places it is not incorrect, the more likely it is to be correct (even if we can't prove it).

I meant that it's over-reach to say it's completely trustworthy just bc it's written in a GC/borrow checked language.

Clearly you can only do worse in Rust than you'd have with perfect C. But what's that?

The question is: what is the expected loss (time, bugs, exploits that lead to crashes or injury or death or financial catastrophe) with Rust vs other languages.

Unfortunately that's not the conversation we have. We instead have absolutism re managed memory, which does account for about half of known security flaws that have been discovered and patched. Removing half of bugs in one fell swoop sounds amazing.

It's not that we can't remove those bugs other ways. Maybe modern c++ can cut bugs in half at compile time too. But Rust seems nicer to play with and doesn't require much more than what it has out of the box. Also it's shiny and new.

Given that Rust is making its way into platforms that Cpp struggled into, it's potentially moot. I sincerely doubt Linux will accept Cpp, but we're on the cusp of Rust in Linux.

Rust and Cpp both have the same characteristics when it comes to speed, they are both very fast, or executable size, they are both minimal size, or reasonable high level compared to say, C.

When it comes to program correctness and diagnostics, one is better than the other, and it is the one created the last 10 years. Linux kernel should definitely move past C, to Rust, Zig or something like that.

Is this clear? Why would the best Rust be worse than the best C?

I am super happy with most features, but demand is demand and people demand runtimes. As a chimera it perfectly represents the modern world.

Is it just because it makes async possible?

Is this all information that should be communicated to a programmer, or is all this info something that should be automatically assessed by a compiler with clear responses automatically to all possible situations specified, black and white, in the code?

If so, if it is the responsibility of the compiler, why release a version of the language, stabilize a spec, where that's not the case?

It also has a much better overall architecture, the best currently available: A third generation microkernel multiserver system.

It provides a protected (with proof of isolation) RTOS with hard realtime, proof of worst case timing as well as mixed criticality support. No other system can currently make such claims.

[1] https://en.wikipedia.org/wiki/Genode

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 weirdos to win some obscene DOD contracts.

Some day I would love to read a report where some criminal got somewhere they shouldn't, and the fact that they landed on an seL4 system stopped them in their tracks. If something like that exists, let me know, but until then I'm putting my chips on technologies that are well known to be battle tested in the field. Maestro seems a lot more promising in that regard.

There is also an interesting case study[1][2] where seL4 was shown to prevent malicious access to a drone. Using seL4 doesn't necessarily make an entire system safe but for high security applications you have to build from the ground up and having a formally proven kernel is the first step in doing that.

I have been fortunate enough to play a small role in developing some stuff to be used with seL4 and it's obvious that the team are passionate about what they've got and I wish them the best of luck

0 - https://news.ycombinator.com/item?id=25552222 1 - https://www.youtube.com/watch?v=TH0tDGk19_c 2 - http://loonwerks.com/publications/pdf/Steal-This-Drone-READM...

Uh, perhaps take a look at the seL4 foundation's members[0], who are using it in the wild in very serious scenarios.

You can learn more about them as well as ongoing development work in seL4 Summit[1].

0. https://sel4.systems/Foundation/Membership/home.pml

1. https://sel4.systems/Foundation/Summit/home.pml

Why in principle should everything we do on computers behave and beshaped like a file?

it's just something that every program running on a computer knows how to do, so why bother with special APIs you have to link against if you can just write to a file? (note you can still develop those layers if you wish, but you can also write a device driver in sh if you wish, because why not?)

Bad abstractions are notoriously problematic, and no abstraction is fit for every purpose.

A fairer analogy would be if everything in the kitchen was bowl-shaped, but you could do bowl-like actions and get non-bowl behavior. Drop the carrot in the peelbowl and it is peeled, drop the carrot in the knifebowl and it is diced, drop the cubes in the stovebowl and they are cooked. Every manipulation is placing things in bowls. Every bowl is the same shape which means you can store them however is intuitive to you (instead of by shape).

People have access to user-mode filesystems and FUSE, people could have made everything have a file-like interface by now if that was desirable - apparently it isn't. And because different tasks are different, it makes sense that they would fit different abstractions and interfaces, wouldn't it?

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 well and removes so much pointless code and mechanisms.

A great example is a old uni demo where a system was built to control X10 outlets and switches (early home automation gear). Each device was a file in a directory tree that represents a building with sub directories for floors and rooms - e.g. 'cat /mnt/admin-building/2fl/rm201/lights' would return 'on' or 'off' (maybe it's a dimmer and its 0-255, or an r,g,b, value or w/e, sky's the limit, just put the logic in the fs). To change the state of the lights you just echo off >/mnt/admin-building/2fl/rm201/lights.

Now you can make a script that shuts all the lights off in the building by walking directories and looking for "lights" then writing off to those files. Maybe it's a stage, all your lights are on DMX and you like the current settings so then you 'tar -c /mnt/auditorium/stage/lighting|gzip >student_orientation_lighting_preset.tar.gz' and do the reverse over-writing all the archived settings back to their respective files. You could even serve those files over smb to a windows machine and turn lights on and off using notepad or whatever. And the file data doesn't have to be text, it could be binary too. It's just that for some things like the state of lights, temperature or w/e can easily be stored and retrieved as human readable text.

That is the beauty and power of 9p - its removes protocol barriers and hands you named objects seamlessly integrated into your OS which you can read/write using regular every day tools. It's a shame so many people can't grasp it.

> "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 than putting it in a low level pretend filesystem driver, on the other side of an arbitrary interface you had to come up with to satisfy an ideology that everything should have to go through this interface, right?

Over Christmas I set some LED displays running, controlled by an RS-232 serial port. It would be possible to echo a line of text to a pretend filename and have it appear on the sign, but there is a command for whether the text is static or scrolling and one for whether the text appears on the top line or bottom line. That information has to be somewhere, either as different paths in the filesystem e.g. /mnt/sign/static/row/top vs /mnt/sign/scrolling/row/top or as formatted content inside the file, or both.

There's a command to change the colour of the subsequent text, which can be used anywhere in the message, many times over - so that can't easily go in the filesystem path so now there needs to be some intermediate structure which both the shell script and the filesystem driver speak, to be able to pass this command through the file interface. With a COM port in Windows, if one script opens it and another script tries to open it then there's a clear error that the port is in use. If a usermode filesystem driver held the com port open, what would happen if two scripts tried to write to these files? Does one get a mysterious "write failed" filesystem error to catch and debug instead of a proper relevant error message? Do they have to proxy error messages through /mnt/sign/meta/error ?

This is one of the most trivial things a computer can do, sending a short text, which is possible with echoing to a com port /dev/ttyS0, and the abstraction idea of making it a file is already creaking under the weight of the task, adding the burden of arbitrary path decisions and data formatting and task-specific escape codes and control sequences, and bodgy-error handling, while assisting with basically nothing - while you can find /mnt/* you get no help with that, no link to any documentation, no further discovery, no interactivity like you get from a command line binary program interface. Much much easier to put the sign's commands directly in a short Python script, isn't it? And other more complex tasks just get more and more intense, as the "plain text" files in /etc/ are an ad-hoc mix of formats and data types and parsing rules and symbolic links to /opt/ and other random places.

As I say in another comment, usermode filesystems never became the default or popular way to do things, why not?

Rust is a good language and I like using it, but there's a lot of magical thinking around the word "safe". Rust's definition of what "safe" means is fairly narrow, and while the things it fixes are big wins, the majority of CVEs I've seen in my career are not things that Rust would have prevented.

The easiest way to escape a container is through exploitation of the Linux kernel via a memory safety issue.

> C-level memory stuff is absolutely NOT the reason why virtualization is safer

Yes it is. The point of a VM is that you can remove the kernel as a trust boundary because the kernel is not capable of enforcing that boundary because of memory safety issues.

> but there's a lot of magical thinking around the word "safe"

There's no magical thinking on my part. I'm quite familiar with exploitation of the Linux kernel, container security, and VM security.

> the majority of CVEs I've seen in my career are not things that Rust would have prevented.

I don't know what your point is here. Do you spend a lot of time in your career thinking about hardening your containers against kernel CVEs?

The thing is, chroots are pretty secure, if you know what you're doing. As long as you run each process as a dedicated uid, with readonly filesystems, without access to /proc or /dev, bar any kernel exploit you should be safe.

The know what you're doing part was where the problems arose. And that's why chroot was considered insecure in practice. People generally put whole Linux installations in chroots, complete with bind mounts or suid binaries. Either way could be a way to get open file handles outside your filesystem, which would make any namespaces a useless spectacle.

Containers are like that. I've seen people doing all sorts of crazy bind mounts, leaving the docker socket accessible, sharing filesystems, or running processes as root.

The kernel exploits are something else, they exist too, and something you at least in theory would patch after they get known. But the sidechannels are a hundred times more prevalent, in any containerized workload that I've seen.

Most kernel exploits are also related to device drivers or file systems, and are often written by third parties. Microkernels were said to contain those by running most of them as processes. That's a good idea, at least in theory. In practice it's tricky because you are dealing with buggy hardware that has DMA access. Any mismatch between a driver and a hardware state risks a system hang, data loss, or security exploit.

Yes, I literally led a team of people at a FAANG doing this.

You're saying the easiest way to escape a container is a vulnerability normally priced over 1 million USD. I'm saying the easiest way is through one of the million side channels.

I'm not looking to argue, I was just annoyed that I was getting so many of the same comments. It's too early for all of this negativity.

If you want to discuss this via an avenue that is not HN I would be open to it, I'm not looking to make enemies here, I'd rather have an earnest conversation with a colleague rather than jumping down their throats because they caught me in the middle of an annoying conversation.

Thanks for being willing to take a step back. I think possibly we are talking about two different things. IME most instances of exploitation are due to much more rudimentary vulnerabilities.

My bias is that, while I did work on mitigations for stuff like Meltdown and Rowhammer, most "code level" memory vulnerabilities were easier to just patch, than to involve my team, so I probably under-estimate their number.

Regardless, if I were building computation-as-a-service, 4 types of vulnerability would make me worry about letting multiple containers share a machine:

1. Configuration bugs. It's really easy to give them access to a capability, a mount or some other resource they can use to escape.

2. Kernel bugs in the filesystems, scheduling, virtual memory management (which is different from the C memory model). It's a big surface. As you said, better use a VM.

3. The kernel has straight up vulnerabilities, often related to memory management (use after free, copy too much memory, etc.)

4. The underlying platform has bugs. Some cloud providers don't properly erase physical RAM. x86 doesn't always zero registers. Etc.

Most of my experience is in 1, a bit of 2 and mitigation work on 4.

The reason I think we're talking past each other a bit is that you're generating CVEs, while I mostly worked on mitigating and detecting/investigating attacks. In my mind, the attacks that are dirt cheap and I see every week are the biggest problem, but if we fix all of those, and the underlying platform gets better, I see that it'll boil down to trusting the kernel doesn't have vulnerabilities.

Discussions on Hacker News understandably lean toward the concerns of application developers and especially greenfield projects run by startups who can take complete control of the full stack if they want to. But running applications using resources partially shared by other applications encompasses a hell of a lot of other scenarios. Think some bank or military department that has to self-host ADP, Rocket Chat, a Git server, M365, and whatever other hundreds of company-wide collaboration tooling the employees need. Do you do it on VMs or containers? If the application in question inherently assumes it is running on its own server as root, the answer to that question doesn't really depend on kernel CVEs potentially allowing for container escapes.

If we're just reasoning from first principles, applications in containers on the same host OS share more of a common attack surface than applications in VMs on the same physical host, and those share more than applications running on separate servers in the same rack, which in turn share more than servers in separate racks, which in turn share more than servers in separate data centers. The potential layers of separation can be nearly endless, but there is a natural hierachy on which containers will always sit below VMs, regardless of the kernel providing the containers.

Even putting that aside, if we're going to frame a choice here, these are not exactly kernels on equal footing. A kernel written in C that has existed for nearly four decades and is used on probably trillions of devices by everything from hobbyists to militaries to Fortune 50 companies to hospitals to physics labs is very likely to be safer on any realistic scale compared to a kernel written in Rust by one college student in his spare time that is tested on Qemu. The developer himself tells you don't use this in production.

I think the annoyance here is it often feels when reading Hacker News that a lot of users treat static typing and borrow checking like it's magic and automatically guarantees a security advantage. Imagine we lived in the Marvel Multiverse and vibranium was real. It might provide a substrate with which it is possible to create stronger structures than real metals, but does that mean you'd rather fly in an aircraft constructed by Riri Williams when she is 17 that she built in her parents' garage or would you rather trust Boeing and whatever plain-ass alloy with all its physical flaws they put into a 747? Maybe it's a bad analogy because vibranium pretty much is magic but there is no magic in the real world.

> But damn, if Linux had been built with safety in mind security would be a lot simpler. Being able to trust the kernel would be so nice.

For its time, it was built with safety in mind, we can't hold it to a standard that wasn't prevalent until ~20 years later

Yes, we're that old.

We can agree that C was definitely the language to be doing these things in and I don't blame Linus for choosing it.

My point wasn't to shit on Linux for its decisions, it was to think about a hypothetical world where safety built in from the start.

Don't worry, in 30 years people will write the same thing about using Rust, assuming that Rust will still be in use 30 years from now.

The Pascal-based operating system is Aegis (later DomainOS), which - with UNIX - is a joint precursor of HP-UX: https://en.wikipedia.org/wiki/Domain/OS#AEGIS .

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.

Check a few of the results. They range from single assembler line (interrupts or special registers), array buffer reads from hardware or special areas, and rare sections that have comments about the purpose of using unsafe in that place.

Those results really aren't "look how much unsafe code there is", but rather "look how few, well isolated sections there are that actually need to be marked unsafe". It's really not "a lot" - 86 cases across memory mapping, allocator, task switching, IO, filesystem and object loader is surprisingly few. (Actually even 86 is overestimated because for example inb is unsafe and blocks using it are unsafe so they're double-counted)

Bug density from `unsafe` is so low in Rust programs that it's just radically more difficult.

My company (not me, Chompie did the work, all credit to her for it) took a known bug, which was super high potential (write arbitrary data to the host's memory), and found it extremely difficult to exploit (we were unable to): https://chompie.rip/Blog+Posts/Attacking+Firecracker+-+AWS'+...

Ultimately there were guard pages where we wanted to write and it would have taken other vulnerabilities to actually get a working POC.

Exploitation of Rust programs is just flat out really, really hard.

As far as I know, the order of magnitudes of container security flaws from memory safety is the same as security flaws coming from namespace logic issues, and you'll have to top that with hardware issues. I'm sorry but rust or not, there will never be a world where you can 100% trust running a malware.

> Fuschia [...] is unlikely to give us the memory safety that a Rust kernel would

Well being micro kernel make it easier to migrate bits by bits, and not care about ABI

Memory safety issues are very common in the kernel, namespace logic issues are not.

"gVisor is an application kernel for containers. It limits the host kernel surface accessible to the application while still giving the application access to all the features it expects. Unlike most kernels, gVisor does not assume or require a fixed set of physical resources; instead, it leverages existing host kernel functionality and runs as a normal process. In other words, gVisor implements Linux by way of Linux."

https://github.com/google/gvisor

You can lock down the allowed kernel syscalls with seccomp and go further with confining the processes with apparmor. Docker has good enough defaults for these 2 security approaches.

Full fat VMs are not immune to malware infection (the impact still applies to the permitted attack surface). Might not be able to easily escape to host but the risk is still there.

No, Docker container was never meant for that. Never use containers with untrustable binary. There is Vagrant and others for that.

I'm replying simply because you're getting defensive with your edits, but you're missing a few important points, IMO.

First of all, the comment I quoted falls straight into the category of if only we knew back then what we know now.

What does it even mean "built with safety in mind" for a project like Linux?

No one could predict that Linux (which was born as a kernel) would run on billions of devices that people keep in their pockets and constantly use for everything, from booking a table at the restaurant to checking the weather, from chatting with other people to accessing their bank accounts. And that said banks would use it too.

Literally no one.

Computers were barely connected back then, internet wasn't even a thing outside of research centers and universities.

So, what kind of safety should he have planned for?

And to safeguard what from what and who from who?

Secondly, Linux was born as a collaborative effort to write something already old: a monolithic Unix like kernel, nothing fancy, nothing new, nothing experimental, just plain old established stuff for Linus to learn how that kernel thing worked.

The most important thing about it was to be a collaborative effort so he used a language that he and many others already knew.

Did Linus use something more suited for stronger safety guarantees, such as Ada (someone else already mentioned it), Linux wouldn't be the huge success it is now and we would not be having this conversation.

Lastly, the strongest Linux safety guarantee is IMO the GPL license, that conveniently all these Rust rewrites are turning into more permissive licenses. Which steers away from what Linux was, and still largely is, a community effort based on the work of thousands of volunteers.

There is nothing about permissive licenses which prevents the project from being such a community effort. In fact, most of the Rust ecosystem is a community effort just like you describe, while most projects have permissive licenses. There's no issue here.

Tell that to Microsoft.

GPL protected Linux when Linux started to become a threat to the most powerful tech company on Earth of the time, famous for their "embrace and extend" tactic.

Rust had no such problem, it was started by a company that every year takes hundreds of millions (81% of their revenues in 2022) from one of the most powerful tech companies on Earth.

1. If using firecracker then you can't do nested virtualization

2. You still have the "os in an os" problem, which can make it operationally more complex

But Kata is a great project.

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 be exploiting, if I may pat myself on the back ever so gently.

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 scenarios. Is docker itself in Rust?

Memory safety is not a magic bullet, the Linux kernel isn't exactly trivial to exploit either these days, although still not as hardened as windows (if you don't consider stuff like win32k.sys font parsing kernel space since NT is hybrid after all) in my humble opinion.

> Linux had been built with safety in mind security would be a lot simpler

I think it was, given the resources available in 1993. But if Trovalds caved in and allowed a mini-kernel or NT like hybrid design instead if hard-core monolithic unix, it would have been a game changer. In 1995, Ada was well accepted mainstream, it was memory safe and even Rust devs learned a lot from it. It just wasn't fun to use for the devs (on purpose, so devs were forced to do tedious stuff to prevent even non-memory bugs). But since it is developed by volunteers, they used what attracts the most volunteers.

The main benefit of Rust is not it's safety but its popularity. Ada has been running on missiles, missile defense, subways, aircraft, etc... for a long time and it even has a formally verified subset (SPARK).

In my opinion, even today Ada is a better suit technically for the kernel than Rust because it is time tested and version stable and it would open up the possibility easily formal-verifying parts of the kernel.

Given how widely used Linux is, it would require a massive backing fund to pay devs to write something not so fun like Ada though.

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...

Chompie certainly worked hard (and is one of if not the most talented exploit devs I've met), but we're talking about a single exploit developer developing highly reliable exploits in a matter of weeks.

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.

Because in reality, the kernel will have to do all sorts of "unsafe" things even just to provide for basic memory management services for itself and applications, or for interacting with hardware.

You can confine these bits to verified and well-tested parts of the code, but they're still there. And because we're human beings, they will inevitably have bugs that get exploited.

TLDR being written in Rust is an improvement but no guarantee of lack of memory safety issues. It's all how you hold the tool.

Every interaction with hardware (disk, USB, TCP/IP, graphics…) need to do execute unsafe code. And we have firmware. Firmware is probably a underestimate issue for a long time :(

Aside from errors caused by undetected undefined behavior all kinds of errors remain possible. Especially logic errors. Which are probably the biggest surface?

Example:

https://neilmadden.blog/2022/04/19/psychic-signatures-in-jav...

Honestly I struggle to see the point in rewriting C++ code with Java just for the sake of doing it. Probably improving test coverage for the C++ implementation would have been less work and didn’t created the security issue first.

That being said. I want to see an #unsafe and #safe in C++. I want some hard check that the code is executing only defined. And modern compilers can do it for Rust. Same applies to machine-dependent/implementation defined code which isn’t undefined but also can be dangerous.

Which was/is a "safe" dialect of C; basically C extended with a bunch of the stuff that made it into Rust (algebraic datatypes, pattern matching, etc.) Though its model of safety is not the borrow checker model that Rust has.

Always felt to me like something like Cyclone would be the natural direction for OS development to head in, as it fits better with existing codebases and skillsets.

In any case, I'm happy to see this stuff happening in Rust.

I'm honestly interested to know, because it sounds like a huge deal here, but in my laymans ears very cool and sci fi!

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. :)

I reminds me of what Linus Torvalds once said when asked about fearing competition, though.

From my memory his answer was something like: I really like writing device drivers. Few people like that and until someone young and hungry comes along who likes that I'm not afraid of competition.

Risc-v is the instruction set architecture, rust is a programming language. You can port languages to target ISAs. Linux can already run in riscv. The ISA of the hardware and the language the software it runs are completely different issues.

Please give us some actual evidence, instead of just saying "you're wrong", because the position you're taking seems extreme and, frankly, bonkers.

My opinion is this is wrong, and I did voice my disagrement and gave my own view on the matter. If there is something extreme here is the karma slash upon displeasing the pro rust people and AI bots on HN.

It's refusing to backup your position with anything more than saying "you're wrong" "you're wrong" "you're wrong". You've repeatedly been asked to explain why RISC_V would be better, why RISC_V changes anything, what you propose for how it would work (e.g. emulators), and you haven't. That's annoying, timewasting, and downvoteworthy.

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.

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.

Also, why does preprocessing matter so much?

Preprocessing does matter because it would be pointless to get rid of the compiler complexity to get instead preprocessing complexity.

For instance x86_64 assembler fasmg has the most powerful preprocessor out there.... because the assembler is actually written using this preprocessor language! So it is very easy to "slip" and to end up using excessively this prepropressor to actually write assembly code which is not an assembler!

....or do you think that because RISC-V is "standard", assembly for RISC-V would run on any hardware?

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 the end). Usually, you only just care of basic static optimizations, like cache line, fetch code window, alignment, which are more writing "correct" assembly code than anything else.

And even with that, in the worst case scenarios, one could write some specific micro-arch code paths, not an issue while thinking long term of many software components life cycle, which would be "installed"/"branched to" at runtime. At least that knowledge would not be hidden deep in the absurd complexity of an optimizing compiler...

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.

While you can write those micro optimizations for each CPU by hand, they not worth the human cost except in very rare situations. In most cases of course you can't measure the difference, as only a couple CPU cycles are saved.

The kernel part of the GPU driver is massive. It is well known, maybe you were misguided: for instance the AMD GPU drivers are gigantic compared to the actual kernel.

clang(llvm) is playing cat and mouse with gcc extensions and recent ISO C tantrums which creeps into the kernel:Linus T. does not resist those, he does resist only the linux useland ABI(syscalls) breakers.

But where you may be right: it seems nvidia hardware programming interface is much cleaner than AMD one and may require much much less code.

The WebGPU programming model is already too high level for a "hardware programming interface". WebGPU is designed to sit on top of other 3D APIs, which in turn sit on GPU vendor drivers, and most of the complexity and 'hidden magic' is in those drivers.

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 - which can be at the drop of a hat.

I'd recommend changing to GPLv3 while your number of contributors is low enough to do it. Otherwise you're just doing free work for your future masters.