One time fee… what a guy. The courses are timeless but mate how are you going to continue to monetise future courses if all existing people get them for free? Genuinely curious - not trying to be a d bag
Great video, and I'd like to reinforce your comments on the merits of unsafe rust. When we work on audits of rust code, we specifically look for unsafe rust first and give the most attention to that, because it is the most likely place for the serious issues within many open source rust projects.
I still think the best motivation for learning a non-C language is when you wrote your umpteenth vector-like library and still find valgrind issues in it. The university I went to IMHO taught C the correct way. Any and all exercises had 10 tries, all of them had to compile without warnings and had to have zero valgrind issues. If you didn't pass in 10 tries, too bad, try again next year. I still remember some people literally bursting into tears while doing the exercises in a computer room.
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.
Miri is *extremely* useful! when I was porting an existing C program, miri ended up catching multiple vulnerabilities that otherwise produced no noticeable side effects when running an existing test suite. Genuinely a gamechanger when writing unsafe code.
Another great tool is loom, which can be used to exhaustively check all possible thread orderings in a multithreaded test suite - this can verify the correctness of concurrent data structures so you can rely on their synchronization while using unsafe.
one thing I think you could have mentioned: Even when writing a good chunk of unsafe code in rust, the LSP rust-analyzer does a pretty good job of giving you a whole lot of warnings when you're trying to do the more "questionable" things you can do inside an unsafe block, it really is a powerful tool to avoid undefined behavior.
honestly, I am by far more concerned about supply chain attacks, which I feel like are more probable to be exploited, have a bigger impact and need less cognitive effort compared to memory vulnerabilities. The sheer amount of libraries used in rust due to user friendly cargo - compared to C/C++ is somewhat scary to me
Same thing with every other package manager, like Github Actions. I maintain a fairly large repo that handles user account tokens and I recently wanted to add a job to automatically run my unit tests. I looked on the marketplace and found 9 different packages, and all they do is wrap the test command from the SDK. The scariest part is they had a fairly substantial amounts of downloads, making supply chain attacks fairly easy against any repo making use of those actions.
@@bdfb-th5ek the problem is that nobody has the time to check all (recursive) dependencies when updating them, while not updating them leaves known vulnerabilities open.. so someone just has to add something malicious to their package edit: Sorry I think I misunderstood you. Yes, for some projects maybe, others can get pretty deep into the system this way already.
Is it possible to have a useful system level lang where you can’t do anything unsafe? So couldn’t deref raw pointers, allocate mem on the heap, etc. I thought the rust unsafe keywords purpose was to create safe wrappers around inherently unsafe code like a vectors get method which is safe because even though it’s trying to read a pointer at any index, it returns None if it’s out of bounds creating a safe interface around a unsafe thing (reading a raw pointer at any index). I just don’t think it’s possible to have a truly 100% memory safe system lang
No, it's not possible. A lot of system architectures have memory mapped IO registers at a particular address, just being able to create and use a raw pointer to one of those registers is a requirement for systems language.
That's the thing people forget. The point of unsafe blocks is you create a safe wrapper around unsafe code that cannot cause any memory unsafety when used in safe code. If your program segfaults the only possible reason are unsafe blocks which are very clearly marked
Unsafe just means the compiler can't guarantee its correctness, you just need to manually and carefully examine the code to make sure it's safe. Everything not marked unsafe in std is safe to use, even if it uses unsafe internally
Since you mentioned you have never played with Miri, I'll take this opportunity to say that Miri immediately detects the use-after-free that cve-rs generates despite the fact that it's exploiting a compiler bug. :D
If anyone wants to do more reading on this, "Rust for Rustaceans" by Jon Gjengset has a fantastic section on unsafe Rust. The rest of the book is also great!
From what I know, the windows crate is a gigantic crate in terms of code size, mostly since it's all generated from windows interface definitions, for all possible windows APIs you could think of (of which there are far more than of eg the linux kernel, since Windows APIs are concerned with more than just the kernel, and also Windows retains backward compatibility for far longer). So yeah, combine that with it being fundamentally FFI calls with a C (like) ABI, it's not really that remarkable that it has the most uses of unsafe of all crates.
"34.35% of crates make a direct function call into another crate that uses the unsafe keyword" - remember tokio has to use unsafe to make use of the context api which is necessary for async runtimes. Additionally, if you're doing anything with Pin, you pretty much have to use pin_project or something similar, which has unsafe under the hood as well. BTW there is an interesting question of methodology: let's consider crate like pin_project: the crate itself just exports a macro and doesn't contain any unsafe code by itself, but the code the macro expands to does contain unsafe, how is it counted? Does the crate using pin_project contain unsafe according to this methodology?
Starts off implying that the 'unsafe' keyword stops the borrow checker. Hmm... OK the rest of the video turned out much better than that opening laid out. Zig is my chosen language the past few months but I wouldn't classify it as a memory safe language in the same category as Rust, VM languages, and scripting languages. It's more memory safe out of the box than C, sure, but that's not the same thing.
15:42 why do you describe zig as a memory safe language (or a language that tastes like it's memory safe)? The first zig program I wrote segfaulted because I was careless with pointers. Is zig even in any way safer than C++? Both have tools to help guide you towards safer patterns, but neither compiler actually verifies that you use them correctly. Don't get me wrong, zig is an excellent language and a huge upgrade safetywise over C, but clumping it with memory-safe languages is a stretch
Is not safe in sense of Rust but has defer and also you must opt-in for null pointers so good start over C, but using pointers you can always shoot the foot off 😅
@@AK-vx4dy yeah, I guess not having null pointers by default is an upgrade over C++. C++ has RAII just like Rust, which fills the same role as defer most of the time. overall, it seems to me like idiomatic C++ would be around as safe as idiomatic zig, but I'm probably missing something important?
@@asdfghyter I wrote C not C++, I don't know full posibilties of zig, I wrote what I remember. And comment was about Zig. But generally zig and idiomatic c++ should be comparable. But I and many people see zig more like current era C replacement.
@@AK-vx4dy yes, absolutely, I was the one who started talking about C++ in my top level comment. There's no doubt that Zig is safer than C, but the question I asked in my first comment is if it's any safer than C++ and if C++ level safety is the standards that LLL means when he says "tastes like it's memory safe"
@@asdfghyter maybe difference is in defaults, starting with that you can literally or just in style write C inside C++, and maybe get warnings, maybe zig directs people to safer paths just by language construction and less safer path need more work to use them and clarity (no behind scene magic), but you must ask LLL himself ;)
The only reason you like Rust is the safety? Hmm... I honestly don't care all that much about the whole safety thing. It's everything else I really like. Sum types, blocks as expressions, traits, etc. It's like the language was designed for me, I like (almost) everything about it. It also has all the features I've been wanting in other languages (most notably sum types and powerful pattern matching/destructuring)
Yes, coming from dynamic typing and haskell background, not having proper sum types (*tagged* unions enabling pattern matching and overloading) in other languages often annoys me (especially when inheritance is overused).
What I love is how powerful the type system is. You can encode every possible si unit, do dimensional analysis at compile time, and all with zero runtime cost!
You know what would be cool? If the OS running the executable could tell you which unsafe block it was in when something crashed, because the compiler left them all labeled and it tracks every time an unsafe block is entered
Sadly, this is not always possible. An unsafe block might not cause a crash outright, but might instead put your application into a UB state, which would lead to a crash at a future point. As an example, it may create a NonZero which actually has a zero value, and crash will only happen when some other code expects that value to be non-zero.
I'm not surprised at that number. Heck, I'm surprised it's not higher. Even syscalls are an FFI, so must be considered unsafe. I have a feeling that the Rust devs have "cheated" some with some of the basic syscalls, so that the number isn't closer to 100%.
If ever Rust "how to" didn't sound like a cult recruitment drive I'd be more likely to adopt it. The problem with "safe" C is that is not taught. 5:00 willing too bet that 90% of the 70% is not validating an external input.
Or dealing with people that makes stack overflow feel loving. I'm fuzzy on the numbers but input sanitation and process chain validation for fault tolerance would be top 10 culprits.
How does rust work for microcontrollers? Writing to memory has inherent side effects that the compiler can't know about. It feels hard to have memory safe code if the memory goes and changes values when you aren't looking
Yes its safe if you use it as intended. I hate to be a pain but when was the last time you used any language as it was intended??? Its my humble opinion that the definition of safe and unsafe languages is irrelevant, when the devoloper writing the code is more unsafe than typhoid mary!
true, but to be fair they haven't done anything bad in like a year. the trademark thing never even went through which a lot of people aren't even aware about
Unsafe isn't actually unsafe. My disappointment is immeasurable. and my day is ruined. I will now learn rust and use unsafe everywhere. _I hope you're happy._
My bias is leaning towards zig. While still generally memory safe, it feels much more ergonomic than rust. But I can acknowledge that I should do some more bigger projects in rust to get a better idea. I think zig is the perfect bridge from c to the modern world
excpet that zig sucks. zig users also called ziggers are idiot who dont know C and dont know rust so they learn the useless language that is never used so their garbage subhumen code cannot be audited because no one uses it.
Totally agree. I definitely find to be Zig more ergonomic than Rust. Though that may be because Rust is supposed to replace C++, while Zig is supposed to replace C.
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.
It's actually not. In fact mere printing to stdout is a fairly complicated thing under the hood. And inherently not thread safe btw. Especially when you realize that stdin/stdout of your process can be manipulated from outside. It opens a way to a whole class of nasty hacks.
Grammar nazi (if I'm actually right): I the opening you said 'and if that underpins Rusts security'. I think you meant to say undermines? AFAIK underpinning something is making it stronger.
Most of the top crates use unsafe as that's the only way to get all the performance. As such most likely a lot of the code you use will have unsafe in the libraries used. And that's fine.
You should really put a timestamp for people who know what is the concept of Rust! Because the beginning of the video was so boring to me: I use Rust a lot so I just wanted your insight on the report! good vid tho
@@tiranito2834 The term "memory safety" has an actual meaning in its context here. I don't even particularly like Rust, I went the Zig path myself, but this argument doesn't even make sense as a "gotcha" against Rust. I personally am not aware of a language that is immune to memory leaks, and AFAIK, no one has ever claimed that Rust is. I think too many people simply don't understand what "memory safety" means, which is evident my some of the replies here.
@user-gi3mb3eu1m This refers to the "leakpocalypse" -- Rust was originally going to prevent memory leaks, but it turned out that it wasn't really possible to isolate them, and Rc (a reference counting pointer type) can always cause memory leaks when used incorrectly. So, safe code is allowed to leak memory.
@@darukutsu that's a fair point. comptime is definitely a nice feature to have. for me personally, the only reason i would use zig is for c interop. it's just so painful with rust. i can see it being a great choice for migrating existing code, but outside of that, i don't know if it's dramatically different enough to successfully convince your company/boss to choose it over c.
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.
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.
Run Cargo-Geiger on your favorite crate that has substantial dependencies. Rust still builds superior software and the abstractions possible in the syntax are extremely underrated (traits, blanket impls, macros etc) as a consideration for the languages value. Theres a lot to be done in language research and Rusts ambitions have definitely left some syntactic loose ends but having gone back and Forth from Rust to C etc. Rust is objectively better for what it sets out to accomplish.
what it does is give you a "standard" to follow when it comes to the question of memory which is better than C which has no standards or principles or guidelines in regards to memory management
@@techpriest4787 Investing into Rust doesn't mean Windows is gonna be re-written in that language. Now more than ever Microsoft is focusing Windows in backwards-compatibility.
I am a new Rust programmer. How would I do this if I wanted to be safe in Rust. I have one master thread. I have 1023 threads that churn out lots and lots of numbers. I have a global structure called status. Each thread can read the structure. When a value in that structure is set to finished, each thread returns all of it's work. Only the master thread is intended to change it. The other thread just watch it to see the system status.
If it's just a bool and missing the value once is acceptable you could easily use unsafe rust to set the value, but if you want to avoid unsafe, atomics like atomicbool are thread safe and cost I believe one extra CPU instruction per read, which, on the scale of a ghz CPU, even 1024 threads aren't going to have a major performance impact over all from a single atomic
@@DissyFanart Depends on the architecture. In x86 most operations are already atomic. The ordering is mostly used so that the compiler doesn't mess it up.
Perhaps it's because I'm not pressured by a time crunch on my project but is it really that difficult to write safe C code? From my experience, writing safe C code wasn't hard at all. I know you make fun of it as a skill issue but it really seems like a skill issue. I see alot of brainlet devs write: `free(p); p = NULL;` and just repeat that instead of wrapping it into a function that will free the pointer and then set it to NULL. If you call `free` on a NULL, nothing will happen and is guaranteed to be safe. Even worse is when a brainlet doesn't write `p = NULL;` at the end. Memory management isn't that hard either. If you can help it, *don't* allocate heap memory. Also, keep a variable that tracks buffer sizes with every allocation so that you can prevent buffer overflows. Input validation isn't just a C issue but every language has to do it.
Actually, delete that too; even shorter: The issue isn't that memory safe C is hard to do, it's that people don't do it. The reason doesn't matter, but it's a truth that having C, _on average_ leads to having unsafe C, and the easiest way to fix that is to not use C.
@@chri-k there is no "not use C". If you're at a job that uses C, there's likely a good reason for it such as embedded devices or operating system kernels. When you get down the assembly level, all bets are off in terms of safety. Also if you're trying to write libraries, you'll need C so it can be used with other languages like LLL showcased in the video with FFI. If someone chooses not to write memory safe C, then that is indeed a skill issue.and the dev needs to practice with C more so that they know how to write C in a way that prevents and/or mitigates unsafe code. I've been writing C for 10+ years so I know the best tips and tricks to prevent bugs and reduce the chances of them occurring.
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?
Why bother to learn a new language ZIG, where there are no string only arrays defined as [u8], string manipulation function are verbose and clunky, and memory allocators are different paradym. Sure there error handling "try syntax" is good. The complier is your enemy. When we already have Rust, why bother with zig ? or Go if you want to stay high level
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."
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. 🤔
if rust has a million haters im one of them if rust has 5 haters im one of them if rust has 1 hater that one is me if rust has no haters im no longer alive if the world is against rust i support the entire world til my last breath ill hate rust
if rust has a million fans i'm one of them if rust has 5 fans i'm one of them if rust has 1 fan that one is me if rust has no fans i've gone to fix the compiler if the world is against rust i'll teach it to the world til my last breath i'll code in rust
I'm thinking lately that my dream language would be something as simple of possible, like C with something like the built-in standard library of Python to back it up and perhaps some of its keywords (with, in and exceptions).
"not calling destructors is consider safe - because memory leakage is considered safe" I am developing a python library and it's main dependency is another library that's basically python bindings for a rust backend via ffi. Bug I run into tons of rust panics or hangs. And it's not trivially understood or even debugged. So I might need to really learn rust to fix some bugs up-up-up-upstream. Some of my code is really awful because I am constantly cresting new descriptors and stuff because nothing seems to be reused, mutable or even just pointing correctly. But its graphics programming so the rules change quite a bit.
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.
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".
@@tdsdave unsafe doesn't "disable safety mechanisms", it just allows the programmer to do 5 things that are fundamentally not statically verifiable to be safe, and that were covered the video.
@@skeetskeet9403 Ah ok , never actually written a word in rust, let alone a program , as you say it was mentioned in the video, my brain fart , so its all a compiler safety net , without unsafe usage various expressions will generate errors and prevent compilation. Will look into it more, though direct de-referencing has me wondering still. Thanks.
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.
It's like people still using raw pointers in C++ because the second you use smart pointers everything breaks because they are safer and then all of the horrible practices that had been used don't work... and people moan that they are not good enough and continue using raw pointers. At least rust forces you to specify you are about to break things
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.
hey! would it be possible to ask you to have a longer VOD where you write the mentioned HTTP server say in rust and then try to break. basically just like you mentioned. I think it would have a really great learning value ...for me at least :)
How much of the memory safety could be put into the C compiler like if there was a flag that would pause compilation and ask for confirmation when there something detectable like an allocation call without a free call? Obviously not the same as Rust, but if some safety could be imported as a harder version of a warning or a soft error (since it is still valid code, just bad code), maybe we could get some benefits in C or C++ as well.
Love your vidoes and the way cover topics. Have you looked into Dynamic Linking (or Shared libraries) in Rust? Would like to hear more opinions about this. Personally it would interest me to have such functionality.
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
There's another Undefined Behavior detection tool called Rudra, which the team used to detect UB and submit CVEs for numerous crates. It's based on a specific version of nightly Rust though, and needs some updating. It still works on crates that can be compiled with its Rust version
Started with Python. Studying C now using the Zig compiler to compile C code. Rust may have the spotlight but Zig is pretty awesome too and easy to work with.
I think you are downplaying the language spec bug with the lifetime allowing "safe" rust to access released memory. The problem of having even convoluted way is that it is not expected and probably not possible to catch in reviews, so determined malicious contributors can eventually hijack complex projects with high probability where nobody expects that. Also IMHO, it is not as convoluted to not appear in code just by accident, when even inexperienced programmers are forced to use one of the most tedious and hard to understand feature of the language.
![[UA] NAVI проти G2 Esports | Blast Premier Fall Final](http://i.ytimg.com/vi/QWlIm4FGESQ/mqdefault.jpg)
wanna learn how computers work? learn to code at lowlevel.academy (get 20% with offer code ARMASSEMBLY20)
One time fee… what a guy.
The courses are timeless but mate how are you going to continue to monetise future courses if all existing people get them for free?
Genuinely curious - not trying to be a d bag
C#
what happened to your lip
Great video, and I'd like to reinforce your comments on the merits of unsafe rust. When we work on audits of rust code, we specifically look for unsafe rust first and give the most attention to that, because it is the most likely place for the serious issues within many open source rust projects.
true it makes it way easier to "ctrl f" it and work on finding a solution.
@@JessicaFEREM software future is in great hands if that's the case that you "fix" code by ctrl+f /s
@rusi6219 what part you didn't understand?
@@rusi6219did you think they meant find-and-replace? they aren't changing the code; they're just looking at it to check for vulnerabilities
@@iykury yes searching bits without understanding the larger context of the codebases such an amazing way to detect vulnerabilities and "fix" them
I still think the best motivation for learning a non-C language is when you wrote your umpteenth vector-like library and still find valgrind issues in it. The university I went to IMHO taught C the correct way. Any and all exercises had 10 tries, all of them had to compile without warnings and had to have zero valgrind issues. If you didn't pass in 10 tries, too bad, try again next year. I still remember some people literally bursting into tears while doing the exercises in a computer room.
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.
Does any actual "C/C++" programmer refer to these languages as one unit?
10:22 Nice
Miri is *extremely* useful! when I was porting an existing C program, miri ended up catching multiple vulnerabilities that otherwise produced no noticeable side effects when running an existing test suite. Genuinely a gamechanger when writing unsafe code.
Another great tool is loom, which can be used to exhaustively check all possible thread orderings in a multithreaded test suite - this can verify the correctness of concurrent data structures so you can rely on their synchronization while using unsafe.
one thing I think you could have mentioned: Even when writing a good chunk of unsafe code in rust, the LSP rust-analyzer does a pretty good job of giving you a whole lot of warnings when you're trying to do the more "questionable" things you can do inside an unsafe block, it really is a powerful tool to avoid undefined behavior.
honestly, I am by far more concerned about supply chain attacks, which I feel like are more probable to be exploited, have a bigger impact and need less cognitive effort compared to memory vulnerabilities. The sheer amount of libraries used in rust due to user friendly cargo - compared to C/C++ is somewhat scary to me
Yeah. That is the same as npm and pip
Those supply chain attacks will need a way to get into each system deeper. So they may need to depend on memory exploits like this in the end
Same thing with every other package manager, like Github Actions.
I maintain a fairly large repo that handles user account tokens and I recently wanted to add a job to automatically run my unit tests. I looked on the marketplace and found 9 different packages, and all they do is wrap the test command from the SDK. The scariest part is they had a fairly substantial amounts of downloads, making supply chain attacks fairly easy against any repo making use of those actions.
@@bdfb-th5ek the problem is that nobody has the time to check all (recursive) dependencies when updating them, while not updating them leaves known vulnerabilities open.. so someone just has to add something malicious to their package
edit: Sorry I think I misunderstood you. Yes, for some projects maybe, others can get pretty deep into the system this way already.
@@bdfb-th5ek Running an executable is a pretty deep in into a system already. Even without root
Is it possible to have a useful system level lang where you can’t do anything unsafe? So couldn’t deref raw pointers, allocate mem on the heap, etc. I thought the rust unsafe keywords purpose was to create safe wrappers around inherently unsafe code like a vectors get method which is safe because even though it’s trying to read a pointer at any index, it returns None if it’s out of bounds creating a safe interface around a unsafe thing (reading a raw pointer at any index). I just don’t think it’s possible to have a truly 100% memory safe system lang
No, it's not possible. A lot of system architectures have memory mapped IO registers at a particular address, just being able to create and use a raw pointer to one of those registers is a requirement for systems language.
That's the thing people forget. The point of unsafe blocks is you create a safe wrapper around unsafe code that cannot cause any memory unsafety when used in safe code. If your program segfaults the only possible reason are unsafe blocks which are very clearly marked
@@kylek.3689yep. Computers are intrinsically unsafe. You always need to deal with stuff that you do not know if it's safe, like doing IO.
@@pxolqopt3597Exactly. The Rust stdlib uses a lot of unsafe under the hood, exposing mostly the safe parts.
Unsafe just means the compiler can't guarantee its correctness, you just need to manually and carefully examine the code to make sure it's safe. Everything not marked unsafe in std is safe to use, even if it uses unsafe internally
Since you mentioned you have never played with Miri, I'll take this opportunity to say that Miri immediately detects the use-after-free that cve-rs generates despite the fact that it's exploiting a compiler bug. :D
If anyone wants to do more reading on this, "Rust for Rustaceans" by Jon Gjengset has a fantastic section on unsafe Rust.
The rest of the book is also great!
From what I know, the windows crate is a gigantic crate in terms of code size, mostly since it's all generated from windows interface definitions, for all possible windows APIs you could think of (of which there are far more than of eg the linux kernel, since Windows APIs are concerned with more than just the kernel, and also Windows retains backward compatibility for far longer).
So yeah, combine that with it being fundamentally FFI calls with a C (like) ABI, it's not really that remarkable that it has the most uses of unsafe of all crates.
I took your advice on learning c then rust a while ago and it was a great decision, thanks for all the mega cool videos
"34.35% of crates make a direct function call into another crate that uses the unsafe keyword" - remember tokio has to use unsafe to make use of the context api which is necessary for async runtimes. Additionally, if you're doing anything with Pin, you pretty much have to use pin_project or something similar, which has unsafe under the hood as well.
BTW there is an interesting question of methodology: let's consider crate like pin_project: the crate itself just exports a macro and doesn't contain any unsafe code by itself, but the code the macro expands to does contain unsafe, how is it counted? Does the crate using pin_project contain unsafe according to this methodology?
Starts off implying that the 'unsafe' keyword stops the borrow checker. Hmm... OK the rest of the video turned out much better than that opening laid out.
Zig is my chosen language the past few months but I wouldn't classify it as a memory safe language in the same category as Rust, VM languages, and scripting languages. It's more memory safe out of the box than C, sure, but that's not the same thing.
15:42 why do you describe zig as a memory safe language (or a language that tastes like it's memory safe)? The first zig program I wrote segfaulted because I was careless with pointers. Is zig even in any way safer than C++? Both have tools to help guide you towards safer patterns, but neither compiler actually verifies that you use them correctly.
Don't get me wrong, zig is an excellent language and a huge upgrade safetywise over C, but clumping it with memory-safe languages is a stretch
Is not safe in sense of Rust but has defer and also you must opt-in for null pointers so good start over C, but using pointers you can always shoot the foot off 😅
@@AK-vx4dy yeah, I guess not having null pointers by default is an upgrade over C++. C++ has RAII just like Rust, which fills the same role as defer most of the time.
overall, it seems to me like idiomatic C++ would be around as safe as idiomatic zig, but I'm probably missing something important?
@@asdfghyter I wrote C not C++, I don't know full posibilties of zig, I wrote what I remember. And comment was about Zig. But generally zig and idiomatic c++ should be comparable. But I and many people see zig more like current era C replacement.
@@AK-vx4dy yes, absolutely, I was the one who started talking about C++ in my top level comment. There's no doubt that Zig is safer than C, but the question I asked in my first comment is if it's any safer than C++ and if C++ level safety is the standards that LLL means when he says "tastes like it's memory safe"
@@asdfghyter maybe difference is in defaults, starting with that you can literally or just in style write C inside C++, and maybe get warnings, maybe zig directs people to safer paths just by language construction and less safer path need more work to use them and clarity (no behind scene magic), but you must ask LLL himself ;)
Rust has more videos on UA-cam than actual lines of code working in production
Is Rust the next white-paper ingredient to replace Haskell?
The fewer live lines of code, the fewer points of failure
I didn't know Sza was concerned with software safety, makes sense since she wrote ghost in the machine
The only reason you like Rust is the safety? Hmm...
I honestly don't care all that much about the whole safety thing. It's everything else I really like.
Sum types, blocks as expressions, traits, etc.
It's like the language was designed for me, I like (almost) everything about it. It also has all the features I've been wanting in other languages (most notably sum types and powerful pattern matching/destructuring)
Yes, coming from dynamic typing and haskell background, not having proper sum types (*tagged* unions enabling pattern matching and overloading) in other languages often annoys me (especially when inheritance is overused).
As a Scala dev, you are appealing to me now
What I love is how powerful the type system is. You can encode every possible si unit, do dimensional analysis at compile time, and all with zero runtime cost!
You know what would be cool? If the OS running the executable could tell you which unsafe block it was in when something crashed, because the compiler left them all labeled and it tracks every time an unsafe block is entered
That's what a debugger is for
Sadly, this is not always possible. An unsafe block might not cause a crash outright, but might instead put your application into a UB state, which would lead to a crash at a future point. As an example, it may create a NonZero which actually has a zero value, and crash will only happen when some other code expects that value to be non-zero.
I'm not surprised at that number. Heck, I'm surprised it's not higher. Even syscalls are an FFI, so must be considered unsafe. I have a feeling that the Rust devs have "cheated" some with some of the basic syscalls, so that the number isn't closer to 100%.
If ever Rust "how to" didn't sound like a cult recruitment drive I'd be more likely to adopt it. The problem with "safe" C is that is not taught. 5:00 willing too bet that 90% of the 70% is not validating an external input.
Or dealing with people that makes stack overflow feel loving. I'm fuzzy on the numbers but input sanitation and process chain validation for fault tolerance would be top 10 culprits.
How does rust work for microcontrollers? Writing to memory has inherent side effects that the compiler can't know about. It feels hard to have memory safe code if the memory goes and changes values when you aren't looking
@@timonix2 you handle it the same way you do in any other language, volatile operations, and not creating any references to that memory.
100% "safe Rust" is not safe by any reasonable definition of the word "safe."
Miri is valgrind on steroids, it's an amazing tool
Yes its safe if you use it as intended.
I hate to be a pain but when was the last time you used any language as it was intended??? Its my humble opinion that the definition of safe and unsafe languages is irrelevant, when the devoloper writing the code is more unsafe than typhoid mary!
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!
The biggest problem with rust is the rust foundation.
true, but to be fair they haven't done anything bad in like a year. the trademark thing never even went through which a lot of people aren't even aware about
And rust users
*CVE-RS MENTIONED* 🗣️🔥🚀
Unsafe isn't actually unsafe.
My disappointment is immeasurable. and my day is ruined. I will now learn rust and use unsafe everywhere.
_I hope you're happy._
My bias is leaning towards zig. While still generally memory safe, it feels much more ergonomic than rust. But I can acknowledge that I should do some more bigger projects in rust to get a better idea. I think zig is the perfect bridge from c to the modern world
excpet that zig sucks. zig users also called ziggers are idiot who dont know C and dont know rust so they learn the useless language that is never used so their garbage subhumen code cannot be audited because no one uses it.
Totally agree. I definitely find to be Zig more ergonomic than Rust. Though that may be because Rust is supposed to replace C++, while Zig is supposed to replace C.
@@ZenonLite Zig replacing C and Rust replacing C++ is just marketing. Both have their own pros and cons for different usages.
Memory safety isn't Rust's top feature, imo. There are a ton of things in Rust that make it easier to work with.
@@tinrabYeah memory safety is an extremely basic and bare-minimum feature
Now, enums and errors-as-values? Incredible
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.
I'd love to see a discussion on modern c++, and how that counts as safe or not, or how to write safer c++
The MIRI tool is a must when writing unsafe. Unsafe rust is not C, it's harder because you need to uphold more invariants
I'd like to see how much rust isn't the external api type unsafe. Those external calls can eventually be made safe as more things are ported.
You know what's safe? "Hello World". Thread safe, memory safe and hack safe.
It's actually not. In fact mere printing to stdout is a fairly complicated thing under the hood. And inherently not thread safe btw.
Especially when you realize that stdin/stdout of your process can be manipulated from outside. It opens a way to a whole class of nasty hacks.
Perfect! Because that's the only code I can write.
char hello[4];
strcpy(hello, "Hello World");
puts(hello);
@@mk72v2oq true
@@mk72v2oq lol, I was kidding, but I didn't mean printf to stdout or stderr, I just meant the string literally.
Gödel & Church strike again..
I have a unsafe macro in rust, and it's called trustme
Grammar nazi (if I'm actually right): I the opening you said 'and if that underpins Rusts security'. I think you meant to say undermines? AFAIK underpinning something is making it stronger.
Rust, not Zig, is the future of safe and reliable software? Dang it. I just started learning a bit of zig...
Most of the top crates use unsafe as that's the only way to get all the performance. As such most likely a lot of the code you use will have unsafe in the libraries used. And that's fine.
You should really put a timestamp for people who know what is the concept of Rust! Because the beginning of the video was so boring to me: I use Rust a lot so I just wanted your insight on the report!
good vid tho
0:00 “Rc causing memory leaks? Don’t worry, memory leaks are safe” - rust
A slow, poorly optimized, memory hogging program is perfectly safe if it does exactly what you expect it to. Which it does if you use safe Rust
@@tiranito2834 Crashing is well defined behaviour. Rust can't stop you from writing bad code.
@@tiranito2834 The term "memory safety" has an actual meaning in its context here. I don't even particularly like Rust, I went the Zig path myself, but this argument doesn't even make sense as a "gotcha" against Rust. I personally am not aware of a language that is immune to memory leaks, and AFAIK, no one has ever claimed that Rust is. I think too many people simply don't understand what "memory safety" means, which is evident my some of the replies here.
WeakRef solves the leak
@user-gi3mb3eu1m This refers to the "leakpocalypse" -- Rust was originally going to prevent memory leaks, but it turned out that it wasn't really possible to isolate them, and Rc (a reference counting pointer type) can always cause memory leaks when used incorrectly. So, safe code is allowed to leak memory.
Who else is just waiting for Zig 1.0?
zig is not memory safe language. i don't even consider it comparable. the main benefit of zig is c interop.
@@smoked-old-fashioned-hh7lo 🤦
@@smoked-old-fashioned-hh7lomain feature of zig is no hidden, unpredictable behaviour imo.
@@darukutsu that's a fair point. comptime is definitely a nice feature to have. for me personally, the only reason i would use zig is for c interop. it's just so painful with rust. i can see it being a great choice for migrating existing code, but outside of that, i don't know if it's dramatically different enough to successfully convince your company/boss to choose it over c.
You will have to pry Python out of my cold dead hands.
Written in C of course, even those libraries you need to load.
@@colinmaharaj Which is written in machine code of course. But the point here is the language you write in.
2 or 3?
Yup, ain't no way I'm stopping python. Especially since it can be compiled to run faster it's definitely my swiss knife.
@@znoppen don't forget only true programmers write in ASM
I wonder how much of unsafe rust is for embedded system calls.
How do you know someone uses Rust?
They tell you.
They harass you for no reason
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.
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.
Run Cargo-Geiger on your favorite crate that has substantial dependencies. Rust still builds superior software and the abstractions possible in the syntax are extremely underrated (traits, blanket impls, macros etc) as a consideration for the languages value. Theres a lot to be done in language research and Rusts ambitions have definitely left some syntactic loose ends but having gone back and Forth from Rust to C etc. Rust is objectively better for what it sets out to accomplish.
what it does is give you a "standard" to follow when it comes to the question of memory
which is better than C which has no standards or principles or guidelines in regards to memory management
Miri is an amazing tool. They keep a ledger on their github of bugs that they have found in prominent crates.
rust std library also full of unsafe code. There’s no escaping unsafe even if you took away the c bindings
You need unsafe for things I consider fairly safe in rust - ie, casting a struct to a byte slice, even if the struct implements Copy.
Sorry, but I will never give up the joy writing code in assembler. 😊
I wonder how much Unsafe Rust is necessary for developing gamers on Windows, 'cause you need to use the Windows API often.
MS does invest into Rust. The future is safe.
@@techpriest4787 Investing into Rust doesn't mean Windows is gonna be re-written in that language. Now more than ever Microsoft is focusing Windows in backwards-compatibility.
What do you think of the Ada programming language ? It provides a lot of tools for writing secure code too.
Name the one programming language for game, web, AI, OS, System design, App etc development and can C do it?
Doesn't really exist from a practical standpoint.
But I guess technically, its C++, hands down
@@devon9374 what about C it's good or bad than C++
C and C++. In terms of getting stuff done, they are here, have always been here, and will always be here.
How do they make Linux API calls in a Linux crate without as many unsafe instances as the Windows crate?
my guess is the linux API just has less functions than the win API, but I'm not sure
I am a new Rust programmer. How would I do this if I wanted to be safe in Rust. I have one master thread. I have 1023 threads that churn out lots and lots of numbers. I have a global structure called status. Each thread can read the structure. When a value in that structure is set to finished, each thread returns all of it's work. Only the master thread is intended to change it. The other thread just watch it to see the system status.
Look up rust AtomicBool/u64/etc. Thread safe and much faster than mutex or rwlock
If it's just a bool and missing the value once is acceptable you could easily use unsafe rust to set the value, but if you want to avoid unsafe, atomics like atomicbool are thread safe and cost I believe one extra CPU instruction per read, which, on the scale of a ghz CPU, even 1024 threads aren't going to have a major performance impact over all from a single atomic
@DissyFanart I am pretty sure atomic types don't cause any overhead on x86_64 cpus unless you use Ordering::SeqCst
@@DissyFanart Depends on the architecture. In x86 most operations are already atomic. The ordering is mostly used so that the compiler doesn't mess it up.
@@Turalcar UB in Rust language is UB regardless of the target architecture.
Whats unsafe about rust? The users mental state after using it.
why
@@arson5304 its rust :)
Only applies for people with 0 skill.
Don't know... Don't care! I already know enough software languages!!!
There was an error in this video: line 69 is always good code.
Rust is like a condom. When used as intended they are 99% safe
I think Zig is much better in stuff that people try to use Rust for xD
c isnt the problem
humans are the problem
we just prefer to externalize blame
accountability is the great filter
love your videos
C IS the problem.
unsafe = bad engineer or lazy developer who would rather use a package than write their own code (note difference between engineer and dev)
nice ironic joke lol
I'd Like to see a video on safety in Zig and how it fares compared to Rust.
Perhaps it's because I'm not pressured by a time crunch on my project but is it really that difficult to write safe C code? From my experience, writing safe C code wasn't hard at all. I know you make fun of it as a skill issue but it really seems like a skill issue. I see alot of brainlet devs write: `free(p); p = NULL;` and just repeat that instead of wrapping it into a function that will free the pointer and then set it to NULL. If you call `free` on a NULL, nothing will happen and is guaranteed to be safe. Even worse is when a brainlet doesn't write `p = NULL;` at the end. Memory management isn't that hard either. If you can help it, *don't* allocate heap memory. Also, keep a variable that tracks buffer sizes with every allocation so that you can prevent buffer overflows. Input validation isn't just a C issue but every language has to do it.
@@chri-k can you give some examples with what you're saying? I'm not quite following what you're saying here.
Actually, delete that too; even shorter: The issue isn't that memory safe C is hard to do, it's that people don't do it.
The reason doesn't matter, but it's a truth that having C, _on average_ leads to having unsafe C, and the easiest way to fix that is to not use C.
@@chri-k there is no "not use C". If you're at a job that uses C, there's likely a good reason for it such as embedded devices or operating system kernels. When you get down the assembly level, all bets are off in terms of safety. Also if you're trying to write libraries, you'll need C so it can be used with other languages like LLL showcased in the video with FFI.
If someone chooses not to write memory safe C, then that is indeed a skill issue.and the dev needs to practice with C more so that they know how to write C in a way that prevents and/or mitigates unsafe code.
I've been writing C for 10+ years so I know the best tips and tricks to prevent bugs and reduce the chances of them occurring.
@@kevinyonan9666 notice that i'm not saying otherwise ( that last one was meant to be from the POV of the organisation )
Thanks. I'm about to start learning Rust
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?
Why bother to learn a new language ZIG, where there are no string only arrays defined as [u8], string manipulation function are verbose and clunky, and memory allocators are different paradym. Sure there error handling "try syntax" is good. The complier is your enemy. When we already have Rust, why bother with zig ? or Go if you want to stay high level
Would love to see an unsafe rust vs zig video
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."
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. 🤔
if rust has a million haters im one of them
if rust has 5 haters im one of them
if rust has 1 hater that one is me
if rust has no haters im no longer alive
if the world is against rust i support the entire world
til my last breath ill hate rust
uhmmm did YOU just say you hate RUST? 😡😤🤬 blud thatzz a skill izzue hurrrr
if rust has a million fans i'm one of them
if rust has 5 fans i'm one of them
if rust has 1 fan that one is me
if rust has no fans i've gone to fix the compiler
if the world is against rust i'll teach it to the world
til my last breath i'll code in rust
@@ToBadILied sad
@@ToBadILiedyou've gyatt to be rizzing me
I'm thinking lately that my dream language would be something as simple of possible, like C with something like the built-in standard library of Python to back it up and perhaps some of its keywords (with, in and exceptions).
"not calling destructors is consider safe - because memory leakage is considered safe"
I am developing a python library and it's main dependency is another library that's basically python bindings for a rust backend via ffi.
Bug I run into tons of rust panics or hangs. And it's not trivially understood or even debugged. So I might need to really learn rust to fix some bugs up-up-up-upstream.
Some of my code is really awful because I am constantly cresting new descriptors and stuff because nothing seems to be reused, mutable or even just pointing correctly. But its graphics programming so the rules change quite a bit.
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.
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".
@@tdsdave unsafe doesn't "disable safety mechanisms", it just allows the programmer to do 5 things that are fundamentally not statically verifiable to be safe, and that were covered the video.
@@skeetskeet9403
Ah ok , never actually written a word in rust, let alone a program , as you say it was mentioned in the video, my brain fart , so its all a compiler safety net , without unsafe usage various expressions will generate errors and prevent compilation. Will look into it more, though direct de-referencing has me wondering still. Thanks.
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.
unsafe { cope::seethe(mald); }
It's like people still using raw pointers in C++ because the second you use smart pointers everything breaks because they are safer and then all of the horrible practices that had been used don't work... and people moan that they are not good enough and continue using raw pointers. At least rust forces you to specify you are about to break things
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.
hey! would it be possible to ask you to have a longer VOD where you write the mentioned HTTP server say in rust and then try to break. basically just like you mentioned. I think it would have a really great learning value ...for me at least :)
How much of the memory safety could be put into the C compiler like if there was a flag that would pause compilation and ask for confirmation when there something detectable like an allocation call without a free call? Obviously not the same as Rust, but if some safety could be imported as a harder version of a warning or a soft error (since it is still valid code, just bad code), maybe we could get some benefits in C or C++ as well.
Love your vidoes and the way cover topics. Have you looked into Dynamic Linking (or Shared libraries) in Rust? Would like to hear more opinions about this. Personally it would interest me to have such functionality.
I agree more with Jonathan Blow
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
There's another Undefined Behavior detection tool called Rudra, which the team used to detect UB and submit CVEs for numerous crates. It's based on a specific version of nightly Rust though, and needs some updating. It still works on crates that can be compiled with its Rust version
Started with Python. Studying C now using the Zig compiler to compile C code. Rust may have the spotlight but Zig is pretty awesome too and easy to work with.
Its called Rust because your ability to write decent code becomes incremntally rusty the more you code with Rust's training wheels
Dude please go outside, you've commenting dumb things in almost every thread
Are/would you consider adding Rust or Zig courses to the Low Level Academy in the future?
Married with Rust, i don't know, the Rust foundation still can take away my children?
she rust till i metal
BASEDDDDDDDD >~
10:20 "you know that line 69 is an issue" 😂
Did that guy who farted in your comments the other day come back?
I'm addicted to exotic unsafe dispatch please send help.
My guess: not much because we've brought our own baggage and previously learned incompetence into it :D
Let's watch the video now, hope I am wrong!
I think you are downplaying the language spec bug with the lifetime allowing "safe" rust to access released memory. The problem of having even convoluted way is that it is not expected and probably not possible to catch in reviews, so determined malicious contributors can eventually hijack complex projects with high probability where nobody expects that. Also IMHO, it is not as convoluted to not appear in code just by accident, when even inexperienced programmers are forced to use one of the most tedious and hard to understand feature of the language.
Miri will help with that.
Can you share link with what about you write here?
@@AK-vx4dy you can search for "cve-rs"
@@AK-vx4dyUA-cam automatically deletes comments that feature links. But you already knew that - typical Rusty gaslighter.
@@rusi6219 I didn't know. You can provide some key words because through whole long comment, author of it strictly avoid naming thing....