6 ms·

yes, that's the point i'm making. saying "if you write your kernel in rust, it will be memory safe" is a little goofy, because writing kernels in rust requires

yes, that's the point i'm making. saying "if you write your kernel in rust, it will be memory safe" is a little goofy, because writing kernels in rust requires you to drop into unsafe blocks way too often.

bluejekyll 7y ago
Not as often as you would think, Phill Oppermann has shown this: https://os.phil-opp.com/ https://os.phil-opp.com/ Unsafe is definitely used, but it does not mean what I think is being implied, which is that it makes the software unsafe.
rapsey 7y ago
The ammount of unsafe blocks is pretty small compared to the rest of the code. Which means those parts can be reviewed more extensively. If anything your argument is pretty goofy.
- DSMan195276 7y ago
  > The ammount of unsafe blocks is pretty small compared to the rest of the code. Which means those parts can be reviewed more extensively. If anything your argument is pretty goofy. I've talked about this at length before, but just because you have 'less' `unsafe` code does not mean you code is any better off. Very few operations are actually `unsafe`, and you're still not allowed to break any of the (poorly or not documented) constraints that Rust requires even in `unsafe` code. Point being, unless you can make "safe" abstractions around your `unsafe` code that cannot be broken (Which is largely what you do in any language anyway, when you can...), the distinction between "safe" and "unsafe" is thin, because the parts of the code you declare `unsafe` are not the parts that are actually going to have the bugs. And because of the fact that the constraints you are required to fulfill in `unsafe` code is unclear, there's little way to guarantee your code is broken in some subtle way the optimizer might jump on (either now, or in a later release). And to be clear, I like Rust, but `unsafe` is poorly thought-out IMO.
  - zozbot234 7y ago
    If you aren't making a safe abstraction around your unsafe code, you're supposed to mark the surrounding function "unsafe" as well, and document its expected constraints in a 'Safety' comment block. In fact, you're supposed to do the same for any piece of code that cannot provide safety guarantees about its use of 'unsafe' features. 'Plain' unsafe{ } blocks should only be used as part of building a safe abstraction.
    - DSMan195276 7y ago
      > If you aren't making a safe abstraction around your unsafe code, you're supposed to mark the surrounding function "unsafe" as well, and document its expected constraints in a 'Safety' comment block. Sure, but now we're back to the issue that it's unclear what constraints `unsafe` code actually has to hold, meaning ensuring your abstraction is safe is just about impossible to do with certainty (And OS kernel code is definitely going to hit on a lot of those corner cases). You may think you have a safe interface, only to find out later you're relying on internal details that aren't guaranteed to stay the same between compiler versions or during optimizations. With that said, while I agree with what you're proposing about marking surrounding code "unsafe", it leads to lots of strange cases and most people get it wrong or will even disagree with this proposal completely. For example, it can lead to cases where you mark a function `unsafe` even though it contains nothing but "safe" code. And at that point, it's up to you to determine if something is actually "safe" or "unsafe", meaning the markings of "safe" and "unsafe" just become arbitrary choices based on what you think "unsafe" means, rather than marking something that actually does one of the "unsafe" operations. One of the best examples is pointer arithmetic. It's explicitly a safe operation, but it's also the first things most people would identify as being "unsafe", even though it is dereferencing that is the "unsafe" operation. Ex. You could easily write slice::from_raw_parts without using any `unsafe` code at all, it just puts a pointer and length together into a structure (it doesn't even need to do arithmetic!). It's only marked `unsafe` because it can break other pieces of "safe" code that it doesn't use, but it itself is 100% safe. You could just as easily argue the "other code" should be the `unsafe` code, since it's what will actually break if you use it incorrectly. Perhaps the biggest annoyance I have is that the official Rust documentation pretty much goes against the idea you presented, saying > People are fallible, and mistakes will happen, but by requiring these four unsafe operations to be inside blocks annotated with unsafe you’ll know that any errors related to memory safety must be within an unsafe block. Keep unsafe blocks small; you’ll be thankful later when you investigate memory bugs. Which is just incorrect - memory safety issues are likely to be due to the "safe" code surrounding your unsafe code - when you're writing C code, the bug isn't that you dereferenced NULL or an OOB pointer, the bug is the code that gave you that pointer in the first place, and in Rust that code is likely to all be "safe". Point being, most of the advice on keeping your unsafe blocks small just leads to people making silly APIs that can be broken via the safe API they wrap (Even in weird ways, like calling a method containing only safe code), and unfortunately there are lots of subtle ways you can unintentionally break you Rust code that most people aren't going to have any idea about.
- phendrenad2 7y ago
  What I find is that, while Rust unquestionably improves the security of software, the argument that you can minimize unsafe code and thoroughly inspect it doesn't tell the full story, because in my experience people end up writing general-purpose unsafe blocks, and while they are controlled by the "safe" outside, the sequence of actions the "safe" code tells them "unsafe" code to execute can lead to subtle bugs.
  - celticmusic 7y ago
    yep, 100% I personally think the Rust community has missed the biggest advantage of unsafe, and that's tooling. Imagine an IDE that could highlight and warn when touching state that is accessed in unsafe blocks, or when state being accessed in unsafe blocks isn't being properly tested. Or tools that kick off notification for a required code review because code that touches state used by an unsafe block got changed. To me, these sorts of things will have a far greater effect on security and stability than just the existence of the unsafe block in code.
    - Cyph0n 7y ago
      But isn’t the most important step having a compiler-enforced keyword for code that seems to be doing unsafe stuff? The rest are just plugins and tools that look for said blocks and “do stuff”. I don’t see why these tools should be part of the language.
      - celticmusic 7y ago
        I never said they should be part of the language, I said the rust community over-emphasizes the "safe" part of having the unsafe keyword and neglected the part that's actually useful in keeping things safe. Another poster responded to me stating they are starting to work on those tools, so it looks like the rust community is starting to come around. It's just that I've seen a lot of people tout the safety of rust as if the unsafe keyword was a panacea that automatically prevented problems. That attitude is really what I was responding to.
pjmlp 7y ago
As proven by the Oberon and Xerox PARC workstations, the amount of unsafe code is quite minimal. Source code is available.
celticmusic 7y ago
The value is in knowing where the unsafe operations are. It could be argued that's not a huge value gain since you're so far down the stack, but that's the value of the unsafe keyword.
gameswithgo 7y ago
the million dollar question is what % of your code has to be unsafe in a kernel. At some %, it ends up not being worth the trouble. But if the % can be kept relatively low (say 5% or less) then you get a lot of value out of minimizing the surface area of the dangerous code.

bluejekyll 7y ago

Not as often as you would think, Phill Oppermann has shown this: https://os.phil-opp.com/ https://os.phil-opp.com/ Unsafe is definitely used, but it does not mean what I think is being implied, which is that it makes the software unsafe.

rapsey 7y ago

The ammount of unsafe blocks is pretty small compared to the rest of the code. Which means those parts can be reviewed more extensively. If anything your argument is pretty goofy.

DSMan195276 7y ago
> The ammount of unsafe blocks is pretty small compared to the rest of the code. Which means those parts can be reviewed more extensively. If anything your argument is pretty goofy. I've talked about this at length before, but just because you have 'less' `unsafe` code does not mean you code is any better off. Very few operations are actually `unsafe`, and you're still not allowed to break any of the (poorly or not documented) constraints that Rust requires even in `unsafe` code. Point being, unless you can make "safe" abstractions around your `unsafe` code that cannot be broken (Which is largely what you do in any language anyway, when you can...), the distinction between "safe" and "unsafe" is thin, because the parts of the code you declare `unsafe` are not the parts that are actually going to have the bugs. And because of the fact that the constraints you are required to fulfill in `unsafe` code is unclear, there's little way to guarantee your code is broken in some subtle way the optimizer might jump on (either now, or in a later release). And to be clear, I like Rust, but `unsafe` is poorly thought-out IMO.
- zozbot234 7y ago
  If you aren't making a safe abstraction around your unsafe code, you're supposed to mark the surrounding function "unsafe" as well, and document its expected constraints in a 'Safety' comment block. In fact, you're supposed to do the same for any piece of code that cannot provide safety guarantees about its use of 'unsafe' features. 'Plain' unsafe{ } blocks should only be used as part of building a safe abstraction.
  - DSMan195276 7y ago
    > If you aren't making a safe abstraction around your unsafe code, you're supposed to mark the surrounding function "unsafe" as well, and document its expected constraints in a 'Safety' comment block. Sure, but now we're back to the issue that it's unclear what constraints `unsafe` code actually has to hold, meaning ensuring your abstraction is safe is just about impossible to do with certainty (And OS kernel code is definitely going to hit on a lot of those corner cases). You may think you have a safe interface, only to find out later you're relying on internal details that aren't guaranteed to stay the same between compiler versions or during optimizations. With that said, while I agree with what you're proposing about marking surrounding code "unsafe", it leads to lots of strange cases and most people get it wrong or will even disagree with this proposal completely. For example, it can lead to cases where you mark a function `unsafe` even though it contains nothing but "safe" code. And at that point, it's up to you to determine if something is actually "safe" or "unsafe", meaning the markings of "safe" and "unsafe" just become arbitrary choices based on what you think "unsafe" means, rather than marking something that actually does one of the "unsafe" operations. One of the best examples is pointer arithmetic. It's explicitly a safe operation, but it's also the first things most people would identify as being "unsafe", even though it is dereferencing that is the "unsafe" operation. Ex. You could easily write slice::from_raw_parts without using any `unsafe` code at all, it just puts a pointer and length together into a structure (it doesn't even need to do arithmetic!). It's only marked `unsafe` because it can break other pieces of "safe" code that it doesn't use, but it itself is 100% safe. You could just as easily argue the "other code" should be the `unsafe` code, since it's what will actually break if you use it incorrectly. Perhaps the biggest annoyance I have is that the official Rust documentation pretty much goes against the idea you presented, saying > People are fallible, and mistakes will happen, but by requiring these four unsafe operations to be inside blocks annotated with unsafe you’ll know that any errors related to memory safety must be within an unsafe block. Keep unsafe blocks small; you’ll be thankful later when you investigate memory bugs. Which is just incorrect - memory safety issues are likely to be due to the "safe" code surrounding your unsafe code - when you're writing C code, the bug isn't that you dereferenced NULL or an OOB pointer, the bug is the code that gave you that pointer in the first place, and in Rust that code is likely to all be "safe". Point being, most of the advice on keeping your unsafe blocks small just leads to people making silly APIs that can be broken via the safe API they wrap (Even in weird ways, like calling a method containing only safe code), and unfortunately there are lots of subtle ways you can unintentionally break you Rust code that most people aren't going to have any idea about.
phendrenad2 7y ago
What I find is that, while Rust unquestionably improves the security of software, the argument that you can minimize unsafe code and thoroughly inspect it doesn't tell the full story, because in my experience people end up writing general-purpose unsafe blocks, and while they are controlled by the "safe" outside, the sequence of actions the "safe" code tells them "unsafe" code to execute can lead to subtle bugs.
- celticmusic 7y ago
  yep, 100% I personally think the Rust community has missed the biggest advantage of unsafe, and that's tooling. Imagine an IDE that could highlight and warn when touching state that is accessed in unsafe blocks, or when state being accessed in unsafe blocks isn't being properly tested. Or tools that kick off notification for a required code review because code that touches state used by an unsafe block got changed. To me, these sorts of things will have a far greater effect on security and stability than just the existence of the unsafe block in code.
  - Cyph0n 7y ago
    But isn’t the most important step having a compiler-enforced keyword for code that seems to be doing unsafe stuff? The rest are just plugins and tools that look for said blocks and “do stuff”. I don’t see why these tools should be part of the language.
    - celticmusic 7y ago
      I never said they should be part of the language, I said the rust community over-emphasizes the "safe" part of having the unsafe keyword and neglected the part that's actually useful in keeping things safe. Another poster responded to me stating they are starting to work on those tools, so it looks like the rust community is starting to come around. It's just that I've seen a lot of people tout the safety of rust as if the unsafe keyword was a panacea that automatically prevented problems. That attitude is really what I was responding to.

pjmlp 7y ago

As proven by the Oberon and Xerox PARC workstations, the amount of unsafe code is quite minimal. Source code is available.

celticmusic 7y ago

The value is in knowing where the unsafe operations are. It could be argued that's not a huge value gain since you're so far down the stack, but that's the value of the unsafe keyword.

gameswithgo 7y ago

the million dollar question is what % of your code has to be unsafe in a kernel. At some %, it ends up not being worth the trouble. But if the % can be kept relatively low (say 5% or less) then you get a lot of value out of minimizing the surface area of the dangerous code.