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.
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.
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.
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.
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!
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
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?
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 ;)
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.
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!
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.
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._
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.
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%.
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.
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.
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
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
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 is sort of a misnomer. You could call it "unchecked" code. Meaning, code that the rust compiler can't check, to see if it is safe or not. So if a certain C function will crash if you pass in an uninitialized struct, rust cannot check for you if it is initialized or not. So you typically write a wrapper around these calls, so you can assume that everything you do with the wrapped API is safe, assuming there isn't a bug in the wrapper code.
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 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.
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.
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.
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.
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.
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
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?
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.
"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.
@@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.
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.
Could you talk about ARC, Automatic Reference Counting in Rust? Could you also compare it to Swift, (which is ARC by default, but recently allows opting into borrow checking)?
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. 🤔
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.
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.
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.
5 місяців тому
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
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."
It's not hard to learn, though. The argument of "it's still unsafe" is just "I don't want to wear a helmet while riding a motorcycle, because it's still unsafe"
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.
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 :)
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
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
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.
Basically there's a bug in the compiler's type inference which they use to extend the lifetime of a string reference to borrow its memory after the compiler frees it. It's not something you would do on accident, though. The file "lifetime_expansion.rs" in the cve-rs repo has an explanation, UA-cam won't let me link it
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'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).
@@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 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.
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
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.
my opnion on rust is that it will be used on online servers and things like it but on machines that do not need to connect to the internet people will probably chose c or c++ instead
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
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!
but in the world of remote work and trusting outsourced code, at least once you encounter the unsafe block you know to give it extra scrutiny in reviews. While not perfect, any little bit will help.
I see it as a change in perspectives, by default you write safe code no matter what, thanks to the guarantees(meaning no oopsies) and when you actually need the potential unsafety, you would heavily scrutinize it as you had to explicitly spell it out, it’s less that Rust is “just safe” more that it is safe by default and can contain(whereas the Cs simply doesnt have a way) where memory issues can possibly happen Or rather, think about it this way, you can switch to Rust, write it exactly how you write C and put it all in an unsafe. Now take out the parts that don’t need unsafe, now you are sure that that part wouldn’t have memory issues(obv it’s not that simple irl, safe code requires unsafe code to behave to be safe). It’s purely an improvement over C in that way
The "unsafe" keyword is still much safer than C. It just gives a bit more flexibility in exchange for the compiler trusting you to uphold constraints it can no longer check.
So calling linux api is not wrapped in unsafe? Or is whole (g)lib(c) rewritten in Rust? So calling linux kernel by fewer functions but with dynamic parameters is safer? Counting by lines is not fair in this example.
A lot of the libc crate is unsafe FFI calls to glibc functions. I don't think that's what you mean, though. The Rust stdlib implements a lot of the functionality that would be in glibc, in pure Rust, using the libc crate for unsafe bindings to things like kernel calls. I'm not sure the point you're trying to make... that every project which uses stdlib is unsafe because stdlib contains unsafe code?
Why do you even need borrow-checker? Why is Rust so focused on limiting the code you write, to prevent one of the easiest to fix issues? In BeefLang for example, you have a leak checker. When you've got a reference that is fit for GC criteria, you get an error. As simple as that. And it's not like deallocating memory is that difficult or takes up so much code space (literally 8 characters or less)
To statically ensure all references are valid. Why are you immediately referring to deallocating memory, that's handled by RAII, not the borrow checker.
@@skeetskeet9403 Because borrow checker complements RAII. Anyway, my point is, dancing around all these constraints during refactors is just pure self-imposed torture, which in rare cases demands you to completely switch to an unsafe context. Having semi-manual deallocation and checking resource validity at a debugtime is much more reasonable in my opinion, if your goal is to actually ship product.
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
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.
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
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.
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!
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
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
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?
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 ;)
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
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!
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.
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._
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!
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.
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%.
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
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.
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 didn't know Sza was concerned with software safety, makes sense since she wrote ghost in the machine
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.
I'd love to see a discussion on modern c++, and how that counts as safe or not, or how to write safer c++
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.
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
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 is sort of a misnomer. You could call it "unchecked" code. Meaning, code that the rust compiler can't check, to see if it is safe or not. So if a certain C function will crash if you pass in an uninitialized struct, rust cannot check for you if it is initialized or not. So you typically write a wrapper around these calls, so you can assume that everything you do with the wrapped API is safe, assuming there isn't a bug in the wrapper code.
The MIRI tool is a must when writing unsafe. Unsafe rust is not C, it's harder because you need to uphold more invariants
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 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.
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.
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.
*CVE-RS MENTIONED* 🗣️🔥🚀
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.
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?
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
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?
Miri is valgrind on steroids, it's an amazing tool
I have a unsafe macro in rust, and it's called trustme
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.
"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.
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.
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.
I wonder how much of unsafe rust is for embedded system calls.
Could you talk about ARC, Automatic Reference Counting in Rust?
Could you also compare it to Swift, (which is ARC by default, but recently allows opting into borrow checking)?
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.
100% "safe Rust" is not safe by any reasonable definition of the word "safe."
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. 🤔
As a formal methods fanatic, we could benefit greatly from logic and proof system for safety inside unsafe blocks
You are going to LOVE ATS.
@@arkeynserhayn8370 whats that?
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.
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'd Like to see a video on safety in Zig and how it fares compared to Rust.
What do you think of the Ada programming language ? It provides a lot of tools for writing secure code too.
Rust, not Zig, is the future of safe and reliable software? Dang it. I just started learning a bit of zig...
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.
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
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."
thank you, too many people keep glazing rust without understanding how rust is hard to learn and it can still be unsafe
It's not hard to learn, though.
The argument of "it's still unsafe" is just "I don't want to wear a helmet while riding a motorcycle, because it's still unsafe"
Rust really isn't hard to learn if you already know a statically typed language. Hard to master, very much so.
@@MaybeADragon it's annoying to read and write, thus harder to learn for beginner.
@@nordgaren2358 wearing a helmet is easy and doesnt require effort unlike writing safe code in rust. unrelated analogy
there is even a repository which managed to create quite a few memory corruptions fully in safe Rust
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
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.
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 :)
Miri is an amazing tool. They keep a ledger on their github of bugs that they have found in prominent crates.
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
10:20 "you know that line 69 is an issue" 😂
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
There was an error in this video: line 69 is always good code.
@LowLevelTV will be a zig course in your academy?
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
Are/would you consider adding Rust or Zig courses to the Low Level Academy in the future?
Would love to see an unsafe rust vs zig video
Thanks. I'm about to start learning Rust
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.
What's the CVRS string lifetime issue you mentioned?
@9SMTM6 provided a awnser in another comment. I would've linked to/copied it if I weren't on mobile.
Basically there's a bug in the compiler's type inference which they use to extend the lifetime of a string reference to borrow its memory after the compiler frees it. It's not something you would do on accident, though. The file "lifetime_expansion.rs" in the cve-rs repo has an explanation, UA-cam won't let me link it
I think my reply got attached to the wrong comment.
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.
c isnt the problem
humans are the problem
we just prefer to externalize blame
accountability is the great filter
love your videos
How do you know someone uses Rust?
They tell you.
They harass you for no reason
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.
I mean I just really like rust because of auto complete and checking data types in my editor. Plus having the result type for methods is very nice.
cargo check is slow if you're running it on every save though. it gets annoying
rust std library also full of unsafe code. There’s no escaping unsafe even if you took away the c bindings
Sorry, but I will never give up the joy writing code in assembler. 😊
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).
I agree more with Jonathan Blow
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.
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....
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
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.
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
I'm addicted to exotic unsafe dispatch please send help.
some think that crabs look like bugs
my opnion on rust is that it will be used on online servers and things like it but on machines that do not need to connect to the internet people will probably chose c or c++ instead
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
Barriers are safe, despite being super easy to deadlock
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!
For years I've dismissed Rust because I've felt that, the "unsafe" keyword was a refutation of itself whole purpose for existing.
but in the world of remote work and trusting outsourced code, at least once you encounter the unsafe block you know to give it extra scrutiny in reviews. While not perfect, any little bit will help.
I see it as a change in perspectives, by default you write safe code no matter what, thanks to the guarantees(meaning no oopsies) and when you actually need the potential unsafety, you would heavily scrutinize it as you had to explicitly spell it out, it’s less that Rust is “just safe” more that it is safe by default and can contain(whereas the Cs simply doesnt have a way) where memory issues can possibly happen
Or rather, think about it this way, you can switch to Rust, write it exactly how you write C and put it all in an unsafe. Now take out the parts that don’t need unsafe, now you are sure that that part wouldn’t have memory issues(obv it’s not that simple irl, safe code requires unsafe code to behave to be safe). It’s purely an improvement over C in that way
The "unsafe" keyword is still much safer than C. It just gives a bit more flexibility in exchange for the compiler trusting you to uphold constraints it can no longer check.
@@nighteulewe get it you failed at C
So calling linux api is not wrapped in unsafe? Or is whole (g)lib(c) rewritten in Rust?
So calling linux kernel by fewer functions but with dynamic parameters is safer?
Counting by lines is not fair in this example.
A lot of the libc crate is unsafe FFI calls to glibc functions. I don't think that's what you mean, though. The Rust stdlib implements a lot of the functionality that would be in glibc, in pure Rust, using the libc crate for unsafe bindings to things like kernel calls. I'm not sure the point you're trying to make... that every project which uses stdlib is unsafe because stdlib contains unsafe code?
Yeah, picking on the Windows crate is pointless. It's just a large API so of course it has a large number of unsafe blocks.
Why do you even need borrow-checker? Why is Rust so focused on limiting the code you write, to prevent one of the easiest to fix issues?
In BeefLang for example, you have a leak checker. When you've got a reference that is fit for GC criteria, you get an error. As simple as that.
And it's not like deallocating memory is that difficult or takes up so much code space (literally 8 characters or less)
To statically ensure all references are valid. Why are you immediately referring to deallocating memory, that's handled by RAII, not the borrow checker.
@@skeetskeet9403 Because borrow checker complements RAII.
Anyway, my point is, dancing around all these constraints during refactors is just pure self-imposed torture, which in rare cases demands you to completely switch to an unsafe context. Having semi-manual deallocation and checking resource validity at a debugtime is much more reasonable in my opinion, if your goal is to actually ship product.
@@tempname8263 Well, I'm very glad that's your opinion. You asked what the point of a borrow checker is, I answered.
is rust related to safety?
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