271–280 of 380 posts
Earlier quoted context omitted.
People who want stable interfaces should not touch anything Linux with a ten-foot pole.
That's only in terms of the driver interface, right? My understanding is that the userspace interface is extremely stable.
So 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…
Please test your website on mobile. 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.
very svelte compared to most cookie notices.
Earlier quoted context omitted.
serious question: how much additional safety do you get over best practices and tooling in modern c++?
It's not possible for me to say. 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…
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.
Earlier quoted context omitted.
serious question: how much additional safety do you get over best practices and tooling in modern c++?
It's not possible for me to say. 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…
Is this clear? Why would the best Rust be worse than the best C?
So 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…
I'm jealous you were able to make time to get this far!
Earlier quoted context omitted.
If you’re willing to implement your own mutex, it actually is possible to enforce! You could make disabling interrupts emit a token and then require the mutex to accept that token as a parameter to its locking behavior.
How would you enforce use of (only) the correct kind of mutex in interrupt context?
Please try to keep this mindset.
Earlier quoted context omitted.
>It's astonishing how far this can boot with less than a third of the syscalls of Linux implemented. 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…
> 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 do…
Earlier quoted context omitted.
Container vulnerabilities are rarely related to memory bugs. Most vulnerabilities in container deployments are due to logical bugs, misconfiguration, etc. C-level memory stuff is absolutely NOT the reason why virtualization is safer, and not something Rust would greatly improve. On the opposite end of the spectrum, you have hardware vulnerabilities that Rust also wouldn't help you with. Rust is a good language and I…
> Container vulnerabilities are rarely related to memory bugs. 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…
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.