what's so safe about unsafe rust?

23 thoughts on “what's so safe about unsafe rust?”

• wanna learn how computers work? learn to code at https://lowlevel.academy (get 20% with offer code ARMASSEMBLY20)

• Could you please cover cve-rs (a repo which contains some examples of how to corrupt memory in 100% safe Rust)? Would like to know how it works and how the Rust team will fix it.

• I mostly exist in high-level data wrangling land, but this channel has been extremely interesting to me. Thanks for breaking it all down for us!

• Would love to see an unsafe rust vs zig video

• c isnt the problem
  humans are the problem
  we just prefer to externalize blame
  accountability is the great filter
  love your videos

• I get why someone would use Rust or Zig over Go, but my understanding is that Go is also memory safe due to runtime checks.

• 15:30 let's quote my professor regarding that: "Why do we use C? Because you need to learn how computers work. Once you are done here you can get yourself a job coding in Python, or C#, or any fancy language you want, but if you don't learn how computer memory and CPU cycles work, your code will be terrible."

• rust std library also full of unsafe code. There’s no escaping unsafe even if you took away the c bindings

• Would the compiled unsafe code be distinct from safe code , would the compiled protective mechanisms or their absence give away a section of a program that is unsafe. You talked of when auditing sources for unsafe key word your attention would be raised, I wonder if possible detecting the absence of the safety mechanisms in compiled code would also possibly be a red flag to a hacker, "here is where to start looking".

• I love rust. The whole memory safety thing makes the compiler intimately familiar with your code so you get correctness for free. Correctness being how accurately the contacts you've defined operate by the rules you intend for them to follow.

• I will never accept tha CISA/DISA statement on code safe languages, not because I don't think its an important point to make, but just because it feels like a such a buck pass for the overall security issues in both public and private infosec applications not just within US infrastructure but outside of it as well.

• I feel like there's a similar mental reminder with requiring to explicitly define an unsafe block that happens when forcing to handle errors. By forcing developers to actively do something, it reminds us that something can go wrong.

• I think the amount of Rust unsafe calls might decrease in the future if developers put an effort to rewrite those crates that use unsafe to make calls to foreign functions.
  For example, I think most crates that deal with database connections, Vulkan API binding, OpenGL binding, device drivers etc are written in C/C++, not in Rust, so if these API bindings get re-written in Rust then this will reduce the amount of unsafe calls. 🤔

• I dont think Rust is more difficult than C/C++, I think they are on the same level of difficulty, I think though that C/C++ is a more stable foundation to begin learning because of Rust's more "modern" features.

• A lot of unsafe exists in mutable iterators, simply because borrow checker is too restrictive. A container that is otherwise 100% safe, would still require unsafe for a mutable iterator.

• 100% "safe Rust" is not safe by any reasonable definition of the word "safe."

• I think the most important misconception about "unsafe" Rust on the Internet is, that after "unsafe" anything and the opposite may happen at the same time and chaos may arise. That is not true. It is somewhat true when calling into external non-Rust-Code, as developers may do anything they want there with Rust-provided data structures, returning them in a state that will crash Rust code sooner or later (most likely by deallocating those structures without having ownership). but within Rust, regarding memory safety the only relaxation is that you may use raw pointers to data. With those pointers you may do anything you want and of course they have the potential to mess things up notably – but for all other types in Rust the standard rules still apply.

  Where I used the unsafe keyword yet (aside from calling ffi) was to check whether bounds checks in indexed access into arrays hurt performance. One can get rid of those bounds checks by using a.get_unchecked[i] or a.get_unchecked_mut(i) instead of a[i], both calls are "unsafe" for obvious reasons, but if you are able to prove that i is well within bounds all the time (which Rust sees only on some very simply-structured occasions), you can go for it and nothing will break. But for some other features of Rust not directly related to memory safety, one is rarely using indexed access into arrays or vectors at all. Iterators are so much more efficient and powerful in Rust. And they are the fastest fancy for loops you can get in Rust. Almost always better then an old-school procedural approach. Never worse.

• SDR, Downgrade Attack (Changing LTE to GSM).
  Attacker collects your device information? For what?
  With Device ID can other attacks be performed? Push? Install? MITM apps? Keyloggers?

  What is the worst that can happen?

• As a formal methods fanatic, we could benefit greatly from logic and proof system for safety inside unsafe blocks

• I have participated in an ai programming contest recently in rust, and was forced to use the unsafe « global static », which was( to my limited knowledge) the only way to store information between calls to to the player_turn function.

• ready for the most cursed programming journey? I learned SQL first then, Bash and Java.

• The most idiotic sentence is "Rust is not memory safe because we can write unsafe rust"
  It's like saying nail cutter isn't safe because it can cut my toung

• Do real Rust programmers have to rely on non-rust code much (C++ libs and other external code)? And, if so, how much and I presume this negates a decent amount of safety.
  Edit: Just got to 12:50 or so and see this is particularly addressed. Sorry all.

Comments are closed.