7 ms·

Rust would help with bugs like the initial memory unsafety. Half the blog post is about resilience even in the face of memory unsafety though, especially since

by chc4 5y ago

Rust would help with bugs like the initial memory unsafety. Half the blog post is about resilience even in the face of memory unsafety though, especially since the entire point is that there only has to be one bug, in any legacy subsystem, to exploit the entire kernel. Using Rust doesn't magically add any of those defense-in-depth mitigations and pessimistic sanity checks.

atoav 5y ago
But it might remove another hole in the swiss cheese security model, which can be worth it.
skavi 5y ago
Do we know what the performance impact of adding all these checks is?
- habibur 5y ago
  Huge. Only checking array bounds on every access degrades performance considerably. But I am waiting for the Rust-OS to complete -- if one is under construction now. We can check how that stands when released.
  - fabianhjr 5y ago
    AFAIK RedoxOS has been bootable for a while now. (Though, a very simple new OS) https://www.redox-os.org/ https://www.redox-os.org/
    - deleted 5y ago
      [deleted]
  - throwaway81523 5y ago
    > Huge. Only checking array bounds on every access degrades performance considerably. I have not found this, at least in application code. There is usually at most a few percent different between v[i] and v.at(i) (the latter checks bounds) with C++ std::vector, for example. So I almost always use .at() these days, and it does catch bugs.
    - gpderetta 5y ago
      wouldn't compiling with _GLIBCXX_ASSERTIONS or the corresponding for your compiler of choice be a better solution? It will also catch quite a few more issues (dereferencing null smart pointers, empty optionals, etc.), while being still relatively lightweight.
      - pjmlp 5y ago
        Not the OP, that is my approach, keep on the bounds checking settings from VC++ also in release builds. And before STL was a thing, all the custom types I had were bounds checked by default.
      - throwaway81523 5y ago
        Thanks, I didn't know (or didn't remember) about this, but it's not clear from the docs that it bounds checks []. I don't find it difficult to use .at(). I'll try the debug mode too, but when I bother writing something in C++ it's usually because I actually care about its speed, so I don't want the overhead to be too bad. https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_macros.html https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_macros...
    - scns 5y ago
      Well, there is the rub. The safe thing to do is more verbose, the unsafe way is in muscle memory. Rust did it the other way around deliberately. But that is easy if you do a new design and don't need to retrofit a safe solution. No snark intended.
      - pjmlp 5y ago
        That is why one should always enable the compiler switches that turn operator[]() into at(), and then only disable them on case by case scenario, if proven worthwhile to do so.
  - volta83 5y ago
    > Huge. Only checking array bounds on every access degrades performance considerably. Citation needed, since all evidence points to the contrary. Could you please point us to a Rust application (there are hundreds of thousands at this point) that gets noticeably faster when disabling bound checks? In servo, a whole web browser written in Rust, the cost of doing this was negligible, to the point that it was barely measurable (1-3%, noise levels for such a big app). Same for Firefox which has a substantial amount of Rust. Go ahead and give Fuchsia a try. You can enable bound checks for a substantial part of Android's user space and not really notice it. Same for Redox, or any operating system kernel written in Rust. You have many large applications to choose from, so please, just point us to 1 for which this is the case. --- Compared with other mitigations already in the kernel, that can cost you up to 50% perf, and that people seem to be ok with, bound checking all the array accesses seems like a no brainer, given that ~70% of CVE are caused by memory issues. When most people think about bound checking all array accesses, they think, for some "i can only think inside the box" reason, that this happens on hardware, for every memory access. But that is not how Rust works. Rust adds bound checks "in Rust", and the Rust compiler and LLVM are really good at removing duplicates, hoisting many bound checks out of a loop into a single bound check at the beginning of the loop, etc. People also think that this is an all or nothing approach, but Rust allows you to manually access without bound checks and do the hoisting manually. So if you find a function in which this makes a big difference, you can just fix the performance issue there manually.
    - tialaramex 5y ago
      For the optimisation, the compiler will even reason that e.g. iterating over the vector necessarily involves knowing the size of the vector and stopping before the end, so it doesn't need to add the bounds check at all because that's redundant. This is easier in Rust because the compiler knows nobody else can be mutating this vector while you're iterating over it - that's forbidden in the language. So, in general, the idiomatic Rust "twiddle all these doodads" compiles to the same machine code as the idiomatic C++ for that problem, even though Rust bounds checked it and C++ didn't care. Lots of Rust checks are like this, they compile away to nothing, so long as what you did is necessarily correct. The Option<NonZeroU64> stuff a few days ago is another example. Same machine code as a C++ long integer using zero as a signal value, but with type safety.
  - pjmlp 5y ago
    I have used C++ since 1993 with bounds checking enabled, it hardly has ever mattered. The very few cases where it actually mattered for project delivery acceptance, were proven with a profiler, and fixed on those single cases only. Most of the time it is just cargo cult taken from C into other languages. Multics had a better DoD security profile assessment than UNIX, thanks to PL/I being bounds checked by default. Mac OS used Object Pascal until they decided to switch to C++ around 1992, it also hardly impacted their sales, using a language with bounds checking.
b112 5y ago
[flagged]
- Cryptonic 5y ago
  Well, denialists often think that the normal guys have mental disorders. The Rust kernel will come one day. Not doing it in the face of todays massive cyber security threads is madness. Even Windows and MacOS will be rewritten in Rust Ahahahahahahahahhahddahhadad runs in circles
  - kwertyoowiyop 5y ago
    After we have rewritten everything in Rust, we will also have to delete all code, stored anywhere, that was written in C/C++. Storing such code will be considered a Thought Crime and punished by exile to the Radioactive Wastelands.
- okamiueru 5y ago
  I'm sure if that was the management attitude that would have welcomed them, it is a win-win situation.
  - b112 5y ago
    Employers don't need zealots or evangelists, they need realists, and people ready to work. Not prattle on endlessly about the latest fad. Rust has some pluses. Yet the evangelism, with the "it fixes everything" lunacy circulating, taints rust, makes legitimate and sane advocates look like nutjobs. I don't have the time to sort the wheat from the chaff, so when I see a big deal made about rust on a resume, odds are it's a zealot, and into the bin with 'em.
    - okamiueru 5y ago
      You are expressing widely different things though. You said you would consider out right rejecting someone and question their mental health for having rust on their resume. Having a tool on a resume, or listing experience with tools, should certainly not be interpreted as someone being a rust zealot, evangelist, "pratting on endlessly", and all the rest of the examples you gave. So, maybe you initially wrote something different to what you actually meant.
lmm 5y ago
Resilience is impossible in C-family languages, given undefined behaviour. Any defence-in-depth checks you add can only be triggered once you're already in an undefined state, so the compiler will helpfully strip them out (this has already happened in Linux and is the reason they build with -fno-delete-null-pointer-checks, but C compilers have very little appetite for broadening that kind of thing).
- IshKebab 5y ago
  That seems like a weird way to do it. Wouldn't it be better to have compile errors if the compiler figures out that it can remove a null check?
  - rcxdude 5y ago
    You would have a huge number of false positives, because if you're doing a bunch of null checking defensively you're going to be doing it redundantly a lot.
    - IshKebab 5y ago
      Right, but if the compiler has proved that you don't need those null checks then you can simply remove them. If you think you do need them then it's a sign you've screwed up somewhere and should fix it!
      - _flux 5y ago
        > Right, but if the compiler has proved that you don't need those null checks then you can simply remove them. This can be the case now, but then later someone adds new code that you did need that null check. > If you think you do need them then it's a sign you've screwed up somewhere and should fix it! Hm, so instead of > Wouldn't it be better to have compile errors if the compiler figures out that it can remove a null check? you wanted the opposite: warn when a null check is there and was actually required :). Not sure if this is a working solution either. Maybe if it was behind a macro, JUST_CHECKING_IF_NULL(x)..
vlovich123 5y ago
Did you read the last part of the article? It explicitly says that Rust (or some other kind of languages guarantees) would absolutely remove the need for more complex runtime measures. Additionally, such checks stop the exploit chain early before it’s able to pick up steam.
- ncmncm 5y ago
  It speculates that Rust would help. That is very far from demonstrating that Rust would actually help. Rust would certainly not help in this instance, because nobody is writing pty handling code in Rust. I.e., using Rust in place B does not help with bugs in place A. Any expectation that Linux would get more secure if some new code were Rust is optimistic to the point of fantasy. The best possible outcome of allowing Rust in kernel code is that the kernel would not become even more insecure as a result of the added Rust code. That would be good, by itself, even if not what we really want. But whether even that would be achieved in practice is still to be demonstrated.
  - vlovich123 5y ago
    I think the point is that as Rust is able to tackle more parts of the kernel, existing code can start to be rewritten in it.
  - smoldesu 5y ago
    The best possible outcome of allowing Rust in kernel code is being able to guarantee type safety, memory safety and perfect concurrency where it's applied. Those 3 pain points are where C fails right now, and it's part of the reason why scheduling on Linux feels 'worse' than Windows or even MacOS at times.
    - ncmncm 5y ago
      I.e., exactly what I just said, but longer.

by chc4 5y ago

atoav 5y ago

But it might remove another hole in the swiss cheese security model, which can be worth it.

skavi 5y ago

Do we know what the performance impact of adding all these checks is?

habibur 5y ago
Huge. Only checking array bounds on every access degrades performance considerably. But I am waiting for the Rust-OS to complete -- if one is under construction now. We can check how that stands when released.
- fabianhjr 5y ago
  AFAIK RedoxOS has been bootable for a while now. (Though, a very simple new OS) https://www.redox-os.org/ https://www.redox-os.org/
  - deleted 5y ago
    [deleted]
- throwaway81523 5y ago
  > Huge. Only checking array bounds on every access degrades performance considerably. I have not found this, at least in application code. There is usually at most a few percent different between v[i] and v.at(i) (the latter checks bounds) with C++ std::vector, for example. So I almost always use .at() these days, and it does catch bugs.
  - gpderetta 5y ago
    wouldn't compiling with _GLIBCXX_ASSERTIONS or the corresponding for your compiler of choice be a better solution? It will also catch quite a few more issues (dereferencing null smart pointers, empty optionals, etc.), while being still relatively lightweight.
    - pjmlp 5y ago
      Not the OP, that is my approach, keep on the bounds checking settings from VC++ also in release builds. And before STL was a thing, all the custom types I had were bounds checked by default.
    - throwaway81523 5y ago
      Thanks, I didn't know (or didn't remember) about this, but it's not clear from the docs that it bounds checks []. I don't find it difficult to use .at(). I'll try the debug mode too, but when I bother writing something in C++ it's usually because I actually care about its speed, so I don't want the overhead to be too bad. https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_macros.html https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_macros...
  - scns 5y ago
    Well, there is the rub. The safe thing to do is more verbose, the unsafe way is in muscle memory. Rust did it the other way around deliberately. But that is easy if you do a new design and don't need to retrofit a safe solution. No snark intended.
    - pjmlp 5y ago
      That is why one should always enable the compiler switches that turn operator[]() into at(), and then only disable them on case by case scenario, if proven worthwhile to do so.
- volta83 5y ago
  > Huge. Only checking array bounds on every access degrades performance considerably. Citation needed, since all evidence points to the contrary. Could you please point us to a Rust application (there are hundreds of thousands at this point) that gets noticeably faster when disabling bound checks? In servo, a whole web browser written in Rust, the cost of doing this was negligible, to the point that it was barely measurable (1-3%, noise levels for such a big app). Same for Firefox which has a substantial amount of Rust. Go ahead and give Fuchsia a try. You can enable bound checks for a substantial part of Android's user space and not really notice it. Same for Redox, or any operating system kernel written in Rust. You have many large applications to choose from, so please, just point us to 1 for which this is the case. --- Compared with other mitigations already in the kernel, that can cost you up to 50% perf, and that people seem to be ok with, bound checking all the array accesses seems like a no brainer, given that ~70% of CVE are caused by memory issues. When most people think about bound checking all array accesses, they think, for some "i can only think inside the box" reason, that this happens on hardware, for every memory access. But that is not how Rust works. Rust adds bound checks "in Rust", and the Rust compiler and LLVM are really good at removing duplicates, hoisting many bound checks out of a loop into a single bound check at the beginning of the loop, etc. People also think that this is an all or nothing approach, but Rust allows you to manually access without bound checks and do the hoisting manually. So if you find a function in which this makes a big difference, you can just fix the performance issue there manually.
  - tialaramex 5y ago
    For the optimisation, the compiler will even reason that e.g. iterating over the vector necessarily involves knowing the size of the vector and stopping before the end, so it doesn't need to add the bounds check at all because that's redundant. This is easier in Rust because the compiler knows nobody else can be mutating this vector while you're iterating over it - that's forbidden in the language. So, in general, the idiomatic Rust "twiddle all these doodads" compiles to the same machine code as the idiomatic C++ for that problem, even though Rust bounds checked it and C++ didn't care. Lots of Rust checks are like this, they compile away to nothing, so long as what you did is necessarily correct. The Option<NonZeroU64> stuff a few days ago is another example. Same machine code as a C++ long integer using zero as a signal value, but with type safety.
- pjmlp 5y ago
  I have used C++ since 1993 with bounds checking enabled, it hardly has ever mattered. The very few cases where it actually mattered for project delivery acceptance, were proven with a profiler, and fixed on those single cases only. Most of the time it is just cargo cult taken from C into other languages. Multics had a better DoD security profile assessment than UNIX, thanks to PL/I being bounds checked by default. Mac OS used Object Pascal until they decided to switch to C++ around 1992, it also hardly impacted their sales, using a language with bounds checking.

b112 5y ago

[flagged]

Cryptonic 5y ago
Well, denialists often think that the normal guys have mental disorders. The Rust kernel will come one day. Not doing it in the face of todays massive cyber security threads is madness. Even Windows and MacOS will be rewritten in Rust Ahahahahahahahahhahddahhadad runs in circles
- kwertyoowiyop 5y ago
  After we have rewritten everything in Rust, we will also have to delete all code, stored anywhere, that was written in C/C++. Storing such code will be considered a Thought Crime and punished by exile to the Radioactive Wastelands.
okamiueru 5y ago
I'm sure if that was the management attitude that would have welcomed them, it is a win-win situation.
- b112 5y ago
  Employers don't need zealots or evangelists, they need realists, and people ready to work. Not prattle on endlessly about the latest fad. Rust has some pluses. Yet the evangelism, with the "it fixes everything" lunacy circulating, taints rust, makes legitimate and sane advocates look like nutjobs. I don't have the time to sort the wheat from the chaff, so when I see a big deal made about rust on a resume, odds are it's a zealot, and into the bin with 'em.
  - okamiueru 5y ago
    You are expressing widely different things though. You said you would consider out right rejecting someone and question their mental health for having rust on their resume. Having a tool on a resume, or listing experience with tools, should certainly not be interpreted as someone being a rust zealot, evangelist, "pratting on endlessly", and all the rest of the examples you gave. So, maybe you initially wrote something different to what you actually meant.

lmm 5y ago

Resilience is impossible in C-family languages, given undefined behaviour. Any defence-in-depth checks you add can only be triggered once you're already in an undefined state, so the compiler will helpfully strip them out (this has already happened in Linux and is the reason they build with -fno-delete-null-pointer-checks, but C compilers have very little appetite for broadening that kind of thing).

IshKebab 5y ago
That seems like a weird way to do it. Wouldn't it be better to have compile errors if the compiler figures out that it can remove a null check?
- rcxdude 5y ago
  You would have a huge number of false positives, because if you're doing a bunch of null checking defensively you're going to be doing it redundantly a lot.
  - IshKebab 5y ago
    Right, but if the compiler has proved that you don't need those null checks then you can simply remove them. If you think you do need them then it's a sign you've screwed up somewhere and should fix it!
    - _flux 5y ago
      > Right, but if the compiler has proved that you don't need those null checks then you can simply remove them. This can be the case now, but then later someone adds new code that you did need that null check. > If you think you do need them then it's a sign you've screwed up somewhere and should fix it! Hm, so instead of > Wouldn't it be better to have compile errors if the compiler figures out that it can remove a null check? you wanted the opposite: warn when a null check is there and was actually required :). Not sure if this is a working solution either. Maybe if it was behind a macro, JUST_CHECKING_IF_NULL(x)..

vlovich123 5y ago

Did you read the last part of the article? It explicitly says that Rust (or some other kind of languages guarantees) would absolutely remove the need for more complex runtime measures. Additionally, such checks stop the exploit chain early before it’s able to pick up steam.

ncmncm 5y ago
It speculates that Rust would help. That is very far from demonstrating that Rust would actually help. Rust would certainly not help in this instance, because nobody is writing pty handling code in Rust. I.e., using Rust in place B does not help with bugs in place A. Any expectation that Linux would get more secure if some new code were Rust is optimistic to the point of fantasy. The best possible outcome of allowing Rust in kernel code is that the kernel would not become even more insecure as a result of the added Rust code. That would be good, by itself, even if not what we really want. But whether even that would be achieved in practice is still to be demonstrated.
- vlovich123 5y ago
  I think the point is that as Rust is able to tackle more parts of the kernel, existing code can start to be rewritten in it.
- smoldesu 5y ago
  The best possible outcome of allowing Rust in kernel code is being able to guarantee type safety, memory safety and perfect concurrency where it's applied. Those 3 pain points are where C fails right now, and it's part of the reason why scheduling on Linux feels 'worse' than Windows or even MacOS at times.
  - ncmncm 5y ago
    I.e., exactly what I just said, but longer.