41–50 of 380 posts
Earlier quoted context omitted.
People who want stable interfaces should not touch anything Linux with a ten-foot pole.
Care to elaborate on this? 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/...
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…
I largely agree, but this seems quite unfair to Linux. > 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.
Earlier quoted context omitted.
I largely agree, but this seems quite unfair to Linux. > 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
I don't think it's that unfair, but I don't want to get into a whole thing about it, people get really upset about criticisms of the Linux kernel in my experience and I'm not looking to start my morning off with that conversation. 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 abou…
Earlier quoted context omitted.
I largely agree, but this seems quite unfair to Linux. > 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
I don't think it's that unfair, but I don't want to get into a whole thing about it, people get really upset about criticisms of the Linux kernel in my experience and I'm not looking to start my morning off with that conversation. 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 abou…
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.
Earlier quoted context omitted.
But GPU drivers require a fairly big team. We must have a GPU hardware programming "standard" first. And I would favor a risc-v kernel instead to avoid the dependency on a super complex syntax (rust) compiler and do gcc-dependency-like mistake all over again. For this reason, eating the bullet and moving on a modern worldwide standard ISA would actually be the real move forward. We have already linux and others tied…
What do you mean a risc-v kernel? One written in RISC v assembly? Because that would be terrible. 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.
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, actually even worse, since rust syntax is much more complex than C with gcc extensions.
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…
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
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…
Memory safety isn’t why containers are considered insufficient as a security boundary. It’s exposing essentially the entire Linux feature surface, and the ability to easily interact with the host/other containers that makes them unsafe by themselves. What you’re saying about VMs vs containers makes no sense to me. VMs are used to sandbox containers. You still need to sandbox containers if your kernel is written in ru…
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…
Memory safety isn’t why containers are considered insufficient as a security boundary. It’s exposing essentially the entire Linux feature surface, and the ability to easily interact with the host/other containers that makes them unsafe by themselves. What you’re saying about VMs vs containers makes no sense to me. VMs are used to sandbox containers. You still need to sandbox containers if your kernel is written in ru…
Earlier quoted context omitted.
Memory safety isn’t why containers are considered insufficient as a security boundary. It’s exposing essentially the entire Linux feature surface, and the ability to easily interact with the host/other containers that makes them unsafe by themselves. What you’re saying about VMs vs containers makes no sense to me. VMs are used to sandbox containers. You still need to sandbox containers if your kernel is written in ru…
The culture around memory safe languages is a positive improvement for programmer zeitgeist. Man though the overreach all the way to "always safe forever" needs to be checked.