5 ms·

You want all of every OS rewritten in Rust? Boy I’ve got bad news for you

howinteresting 5y ago
Directionally, yes, I want more parts of more OSes written in Rust and other languages that allow building safe abstractions over unsafe code. This is table stakes in 2022.
- deleted 5y ago
  [deleted]
dangus 5y ago
Apple is already writing more of the OS in Swift: https://blog.timac.org/2021/1219-state-of-swift-and-swiftui-ios15/ https://blog.timac.org/2021/1219-state-of-swift-and-swiftui-...
- ksec 5y ago
  Most of them are Apps. Not what I considered as "OS"
  - pjmlp 5y ago
    To be fair, they need to start somewhere, and if userspace gets more secure, it is an easier sell to non-belivers. Think a bit like Android, versus the hard battle from .NET on Windows with WinDev love for C++/COM.
McMiniBurger 5y ago
could you elaborate on the "bad news" part? Is there something rust inherently can't do but c/c++ can?
- izacus 5y ago
  Exist 20 years ago when the OS was written.
  - Someone 5y ago
    Even ColorSync, which the top of this thread mentioned, is older than that. It was first released in 1993 (https://en.wikipedia.org/wiki/List_of_macOS_components#ColorSync_Utility https://en.wikipedia.org/wiki/List_of_macOS_components#Color...) The work to remove all AT&T code from BSD started in 1989, so other parts of MacOS probably are over 30 years old, too. I don’t think anything of the original Mac OS remains, lots of it being written in 68k assembly and pascal.
- vineyardmike 5y ago
  Yea, rust doesn't already exist. Rewriting a whole OS is an impossibly high ask.
- deleted 5y ago
  [deleted]
vineyardmike 5y ago
Rust? You mean swift right?
pjmlp 5y ago
It is quite telling that every single time one talks about secure OSes, someone has to bring out Rust. The parent only mentioned "use a memory safe language", yet Rust it must be. No, it could have been JOVIAL, NEWP, PL/I, BLISS, Modula-2, Modula-3, Oberon, Object Pascal, D, Nim, System C#, Ada, Swift, ....
- ksec 5y ago
  That is why i keep mentioning Ada in the hope to balance the "Memory Safe language" selection bias. I only mention it a few times whenever the topic of memory safe language and Rust came up. And I have already been asked to stop.
  - tasogare 5y ago
    Please keep fighting. The automatic association here on memory safe language with Rust annoys me as well, just as the one about mixing languages on a VM and WebAssembly. Both features are available since decades on C# and the CLR, and Java and the JVM to name a few.
  - pjmlp 5y ago
    I guess there are multiple issues with memory safe language bringing Rust into the talk. One is the naive one, someone that lacks the proper background and for whatever reasons thinks it is the only way, thus Rust. Then we have those that are aware, but think all the other safety approaches are not valid for whatever reason, thus Rust. Then we have those that kind of feel threatened by the security awareness that Rust brings into the picture, so whenever we talk about security, there is pavlovian reaction that it must be Rust when the subject is security. Picking any language that embraces bounds checking enabled by default, and proper string/arrays, is already a major improvement.
    - bigbizisverywyz 5y ago
      >Picking any language that embraces bounds checking enabled by default, and proper string/arrays, is already a major improvement. Even bog standard C can be made safe, and include bounds checking if you create and consistently use an API that supports that mindset - see for e.g. Microsoft's string safe lib (not that I'm saying that is the epitome of such a thing). However the will and the effort has to be there, C is an incredibly flexible and capable language and can be as safe as you want it to be. The last Random ascii article I read, he found an easily exploitable buffer overflow in iOS simply by checking the code to see where it used memmove and worked out the exploit from there, guessing correctly that there was no bounds checking. So it seems that the usual culprits are fairly easy to spot, but somebody needs to replace the worst APIs with something safer (memmove, memcpy, memset, malloc, a = b).
tialaramex 5y ago
The quote was "corrupt file corrupts important memory" which is exactly what WUFFS is for. In Rust you can screw up badly enough to still have the bug, doing so is harder but not impossible - but in WUFFS the stupidest file format parsing you can do is merely wrong and can't corrupt anything. In WUFFS possible outcomes of incompetent morons reading an image file include: the colours in the image are wrong, the image is just a solid black or white rectangle because they didn't remember to actually render the image, bits of it are smashed up somehow, and so on. Notice how it's always about the image? WUFFS can't express programs that do other stuff. General purpose languages are cool, but their unlimited expressiveness is exactly what you don't want for security. Why is this PNG loader able to make network connections and control my camera? You know a bad guy will find a way to force it to use those capabilities right?

Directionally, yes, I want more parts of more OSes written in Rust and other languages that allow building safe abstractions over unsafe code. This is table stakes in 2022.

deleted 5y ago
[deleted]

dangus 5y ago

Apple is already writing more of the OS in Swift: https://blog.timac.org/2021/1219-state-of-swift-and-swiftui-ios15/ https://blog.timac.org/2021/1219-state-of-swift-and-swiftui-...

ksec 5y ago
Most of them are Apps. Not what I considered as "OS"
- pjmlp 5y ago
  To be fair, they need to start somewhere, and if userspace gets more secure, it is an easier sell to non-belivers. Think a bit like Android, versus the hard battle from .NET on Windows with WinDev love for C++/COM.

McMiniBurger 5y ago

could you elaborate on the "bad news" part? Is there something rust inherently can't do but c/c++ can?

izacus 5y ago
Exist 20 years ago when the OS was written.
- Someone 5y ago
  Even ColorSync, which the top of this thread mentioned, is older than that. It was first released in 1993 (https://en.wikipedia.org/wiki/List_of_macOS_components#ColorSync_Utility https://en.wikipedia.org/wiki/List_of_macOS_components#Color...) The work to remove all AT&T code from BSD started in 1989, so other parts of MacOS probably are over 30 years old, too. I don’t think anything of the original Mac OS remains, lots of it being written in 68k assembly and pascal.
vineyardmike 5y ago
Yea, rust doesn't already exist. Rewriting a whole OS is an impossibly high ask.
deleted 5y ago
[deleted]

vineyardmike 5y ago

Rust? You mean swift right?

pjmlp 5y ago

It is quite telling that every single time one talks about secure OSes, someone has to bring out Rust. The parent only mentioned "use a memory safe language", yet Rust it must be. No, it could have been JOVIAL, NEWP, PL/I, BLISS, Modula-2, Modula-3, Oberon, Object Pascal, D, Nim, System C#, Ada, Swift, ....

ksec 5y ago
That is why i keep mentioning Ada in the hope to balance the "Memory Safe language" selection bias. I only mention it a few times whenever the topic of memory safe language and Rust came up. And I have already been asked to stop.
- tasogare 5y ago
  Please keep fighting. The automatic association here on memory safe language with Rust annoys me as well, just as the one about mixing languages on a VM and WebAssembly. Both features are available since decades on C# and the CLR, and Java and the JVM to name a few.
- pjmlp 5y ago
  I guess there are multiple issues with memory safe language bringing Rust into the talk. One is the naive one, someone that lacks the proper background and for whatever reasons thinks it is the only way, thus Rust. Then we have those that are aware, but think all the other safety approaches are not valid for whatever reason, thus Rust. Then we have those that kind of feel threatened by the security awareness that Rust brings into the picture, so whenever we talk about security, there is pavlovian reaction that it must be Rust when the subject is security. Picking any language that embraces bounds checking enabled by default, and proper string/arrays, is already a major improvement.
  - bigbizisverywyz 5y ago
    >Picking any language that embraces bounds checking enabled by default, and proper string/arrays, is already a major improvement. Even bog standard C can be made safe, and include bounds checking if you create and consistently use an API that supports that mindset - see for e.g. Microsoft's string safe lib (not that I'm saying that is the epitome of such a thing). However the will and the effort has to be there, C is an incredibly flexible and capable language and can be as safe as you want it to be. The last Random ascii article I read, he found an easily exploitable buffer overflow in iOS simply by checking the code to see where it used memmove and worked out the exploit from there, guessing correctly that there was no bounds checking. So it seems that the usual culprits are fairly easy to spot, but somebody needs to replace the worst APIs with something safer (memmove, memcpy, memset, malloc, a = b).

tialaramex 5y ago

The quote was "corrupt file corrupts important memory" which is exactly what WUFFS is for. In Rust you can screw up badly enough to still have the bug, doing so is harder but not impossible - but in WUFFS the stupidest file format parsing you can do is merely wrong and can't corrupt anything. In WUFFS possible outcomes of incompetent morons reading an image file include: the colours in the image are wrong, the image is just a solid black or white rectangle because they didn't remember to actually render the image, bits of it are smashed up somehow, and so on. Notice how it's always about the image? WUFFS can't express programs that do other stuff. General purpose languages are cool, but their unlimited expressiveness is exactly what you don't want for security. Why is this PNG loader able to make network connections and control my camera? You know a bad guy will find a way to force it to use those capabilities right?