Yeah, I was screaming: "Add double quotes!" Surprised that you can develop games from a good part of your life then don't know how to use google. But yeah, as he is developing in his own language, he does not really have to use google to search the documentation...
note that this is because of how x86_64 works, on aarch64 it says the feature is considered production ready. additionally, while mshstk might not be available on x86_64, other mechanisms that work similarly do, like safestack. so the point made in the video still stands
Well "nobody cares" is a bold statement nowadays when more and more people and companies seem to care. He called out Microsoft which started caring after they found out they spend billions of dollars every year on fixing this stuff that "nobody cares" about. Apparently someone does care and they do care enough to want to stop it (and save those billions and do something else with them...). And the reason why is actually simple but big companies had to find out the hard way - opt-in software security does not scale. If the developers are allowed not to do it they will no do it. And as it turns out it is impossible to police it at large scales. And then it costs the company incomprehensible amount of money to fix later. So it is only pragmatic wanting to fix it. But that is on macro level. What about individual level. Well turns out we are people and even gods of programming like Jon will inevitably make mistakes. It takes just one on a particularly wrong place and big issue is born. Wouldn't it be nice if we had a way not to make such mistakes in the first place... oh. So yeah, I don't buy the argument here as it seems contrary to what he claimes elsewhere (sw is shit nowadays). Well if you bash every way that will (force) it better then don't be surprised it magically does not become better.
Microsoft uses something called SAL which puts enough metadata on the function prototypes so it can be statically checked automatically for buffer and memory management problems. The thing is having something to do the analysis, having it mandatory in the programming language and compiler is one way of having programmers use it by force. You could try that with C++ and indeed that's what Microsoft does and Microsoft can enforce it via company policy. The advantage of having the programming language enforce it is that it will work for the rest of the industry, which might not have proper policies to enforce the correct way will also benefit from the checking. Another plus which a new programing language is getting rid of 30 years of accumulated cruft in C++, which is always a win. The disadvantage is needing to rewrite code.
Stack cookies (a different security mitigation than shadow stacks) are enabled by default in MSVC. 8:56 Shadow stacks do have hardware support as of Intel 11th gen (so-called CET). Adoption has been underway but is not the default yet.
While I'm sure I'm nowhere as good a programmer blow is, I really don't get his completely nuance-less takes on these things. Not even a rust fanboy or anything, but "uhhh who cares, all these issues are trivial for a Nietzschean ubermensch 10X giga programmer" take is always so stupid. Even as shit as trends in software are, many appear for a very good reason, especially in this case. No matter how perfect you are, other people for the most part are rеtarded, so you'd think it would make sense to not let them blow their foot off and yours by proxy when you have to work in any codebase your divine mind has not produced from scratch
If you are an engineer working on nuclear reactors, stuff wil be hard, you will need a lot of training, checks, security, ... but the work is hard and you will have to make it good or face a nuclear incident. In software engineering? It doesn't matter, incompetence is fine because we're used to "oh the program crashed". Why don't we have the same level of standard in a field that is used by a vast majority of the population, that our whole society now depends on?
The issue is shadow stack is part of intel CET was promptly defeated anyway (look up mcaffee paper on this), and the cost is non-trivial. I looked up some papers, and they showed a case 10^7 magnitude slow down with a fully CET compiled program. Amd's solution is apparently even weaker :/
@@knufyeinundzwanzig2004 I promise you much smarter people than me have looked into this and determined it's not worth it. Safestack is even less safe and has been pwned with like a 30 asm instruction demo iirc?
So, Jon just skill issue'd us. My experience is that the code is usually written by monkeys who will twist every little language feature into a monster, slow and full of bugs. The whole Frontend world invented massive guard rails (e.g. React) specifically to counter this, it's been working alright so far (if you disagree, go to jQuery times for a moment). I feel that we need similar stuff on a system programming side. I mean, we've had types for a half a century now. We now need more innovations. Jon is right that most of us don't even try, but Jon is wrong because we will not try unless forced. You don't measure others efficiency by your own. Compiler flags are cool but useless because they are optional. We need more sensible defaults.
People don't bother because it's incredibly tedious to intently put every buffer at a specific memory arena location. Most programs don't preallocate memory, lots of developers don't care or know enough to use a shadow stack or run sanitizers. So it is an issue because people generally don't follow the best practices all the time and that causes issues, so I think it's good that the compiler is the jerk that politely yells at them to do so (by default).
And educating your devs on the matter, making sure they care is easier than teaching them a new programming language that forces it on them (also rewrite your program in Rust)
@@edhahaz Making sure they care doesn't solve the problem, statistics proff that. Also, you don't have to rewrite your code using Rust, you can develop new modules in Rust and integrate existing C and C++ code into the same system, it works really well
If it’s too hard to get people to turn on a compiler flag they’re really not going to be happy learning a new language. Especially a language like Rust that has a steep learning curve and is very un C-like. Lazy Rust programmers are still going to create bugs, just of a different sort.
Almost every c programmer or c++ programmer has their own abstraction over creating buffers memory arenas etc... its trivial stop those kinds of buffer overflow accesses or out of bounds errors.
@@ALIENdrifter66 New system languages should be easier and faster to develop with not slower and harder so Rust for game dev is a big fat L. For other security critical areas its fine as long as you dont care how long it takes.
Death by a thousand cuts is a well-known idiom. Sometimes we leave dead code around for months at a time. Sometimes we can't hire someone working at $200k salaries who know all the ins and outs of handling a knife with a duct-taped handle. Sometimes old-ass languages are stuffed with committee that don't have the time or mental flexibility to ascertain that a major, backwards-incompatible version bump can be a good thing. I can't even tell if this should even be a rant about Rust, as much as it is about older languages that haven't polished themselves or their tooling around blatant, well-known issues. We clutch our pearls over the need to read every book about the C standard and the ins and outs of a compiler just to make a goddamn GUI app or simple videogame. Why is it supposed to be more complicated than installing the compiler and writing your program? The compiler is literally looking at your code. Books can't look at your code. People don't want to look at your code. Looking at your own code is often repulsing in hindsight. Frankly, online software culture fucking sucks as a whole, and I don't know if it'll ever change, regardless of who makes whatever language do whatever.
I read an explanation on stack overflow about how you should never use system() because of security issues. I went and researched the potential dangers of using system(), and immediately began using it again. Yeah people are insane... it almost always seems to be the linux/haskell/Rust/hacker news people as well. I'm not saying everyone who uses these things is crazy... just that they seem to attract crazy.
Summarizing analogy. Hopefully close enough representation of his position Imagine there is a dangerous bridge with no guard rails. We've known about how to build and apply guard rails for years, but for some reason nobody does. It's stupid and yes we should put up guard rails, but cars driving off the edge is apparently rare enough nobody cares. Yes you could rebuild the entire bridge so that cars slot into a rails system and it is impossible for them to steer incorrectly, and that would be a lot safer, but why bother replacing the whole thing when we could just do the guard rails.
I think he's also implying that there are other problems, more significant than the guard rails, that we prioritized in the past, discarding buffer overflows as something trivially solvable. But now because of Rust, we are overblowing the problem of the guard rails and potentially ignoring other things that might be more important. In other words - bike shedding. Spending more time thinking about how the bikes need to be kept safe than building the damn nuclear power plant. (I don't necessarily agree with him but I think that's what he is implying)
Perhaps the big influencers in the compiler world never really wanted to protect from buffer overflows, because then how else would the intelligence agencies be able to backdoor damn near everything?
@@Alex-qq1gm You realise that there is a large subset of all possible programs (this subset includes all the ones you would ever actually use for any practical purpose) for which it is deterministic whether they halt or not, right? And that the halting problem is pretty much only of theoretical interest because of that fact? Well, memory leaks are even better than that, because if you understand the logic of your code correctly, you will identify memory leaks 100% of the time. So just make sure you know what you are telling the computer to do, and you won't have a problem!
@@slynt_ bad programmers are going to write code. Your "just think harder" solution doesn't help them, or anyone that has to work with them. If you had spent 5 seconds actually thinking about the problem we are trying to solve you'd realise that.
I know people are going to kill me over this but... isn't span the same concept as a fat pointer? I have been working more on C++ than other languages but I still don't understand it because I find it an incredibly frustrating language.
@@MrAntraxico AFAIK there are multiple kinds of fat pointers, e.g. when it comes to dynamic dispatch, a fat pointer would have pointers to both the data and the virtual table (normal C++ pointers are always "thin" and the virtual table pointer is stored within the dynamic object), and that is quite different from a span, which is just a slice/view of continuous data
That's grand. But now if you use it your code is less readible and any old coder will come along and complain about you using a feature he had to look up. I'd rather separate from these people in the beginning, that way they know "uh, he's using rust, he's a hopeless cause" and I have peace of mind in being able to use all the fancy new features without having to justify myself to anyone - or at least being afraid of having to do that - , because you know what, they're all on by default. Also, correct me if I'm wrong, but I think spans are not yet supported in clang. If that's the feature I remembered and wanted to use in some C++ code, only to realize it wasn't possible. I wanted to reduce the ridiculous length of for loop headers, caused by me wanting to give the running variables speaking names, combined with the fact that you'll need to mention the running variable 3 fucking times in the header.
I think Jon meant that nobody decent cares about this problem, not actually 'everyone'. Obviously most of you can't program so you care about trivial problem and Jon knows that
I'm surprised he didn't mention heap-related security bugs, since those are much harder to fix and where Rust is unique compared to other modern langs. Most memory-safe langs do it with garbage collection or reference counting, but Rust does it at compile-time with the borrow checker, leading to the same safety with C-level performance.
...until malware is embedded in the Rust compiler and distributed to Rust developers who don't understand what that entails. You guys do understand that happens right? If you do, then great, but what about all the other Rust devs? Malware is probably already pouring into that community, and the bigger it gets, the more likely it will become a target. Do you know how to find out if your compiler is safe? If you don't, then you are vulnerable. That doesn't mean that we can only use JIT compiled langs like Python... because they are vulnerable too... one language is NOT going to solve this problem with just a compiler. Package managers create far more vulnerabilities than manually acquiring libraries, so does that mean we shouldn't use them? What about browsers? I'm sick of this idea that Rust fixes everything. It doesn't... developers need to step up and learn about security if they care about it. Stop leaving it to the compiler, or the language, or whatever else you place your faith in.
@@malusmundus-9605 When has malware been embedded into a complier? I know the "reflections on trusting trust" attack is theoretically possible and there was a demo of it, but I don't know of any cases of it being applied in practice. Unfortunately, no language is immune from it unless it has a fully documented and reproducible bootstrap chain, which is very hard to do and likely requires lots of custom hardware, since malicious hardware is theoretically possible too. But it's, very unlikely any popular compilers are infected, IMO.
what about memory arenas. you dont need raii or gc just combine the lifetimes of things that go together and use scratch space. that trivializes 99% of cases.
@@malusmundus-9605LOL Are you good? My guy we have a language that solves a problem and all you have to say about is "but it does not solve THIS other problem" which no language can solve. Maybe u need meds 🤡
I'm sorry, I know he's great, and whatnot, but he comes across as uninformed on the issue, it's just hand-waving... "Yeah, no, it was fixed in the nineties. I just don't remember how, when, or anything, really, but trust me, it's trivial to fix, and the fix is great... but for some reason it's not on by default, but I'm sure that's not relevant to my rant, at all".
you dont need the language to protect you from buffer overflows its about writing code that cant fail in a language that gives control like c. memory safety is not a language feature is the point.
Jon's opinions on Rust always seem based on the reality of game dev exclusively, but he never actually makes this distinction. Yeah, no one cares about buffer overflows in a video game. But what about OSs? Drivers? Critical embedded stuff? There are segments of the industry where it's a matter of *ethics* to make sure every security mechanism possible is used.
Well, there's a lot to unpack here... First, if you had listened for more than 2 minutes you would know that you are wrong about that statement regarding Jon... He literally brings in about 1 and a half minutes in one of the biggest problems of buffer overflows, being the way that literally many linux kernel bugs has allowed people in the past to have priviledge escalation exploits and such... so it shows he knows what he's talking about, and cares. His point is not that we should not care about buffer overflows, the point is that nobody should care about preventing them at the language level because even in languages with 0 protection it is trivial to prevent them if you know what you are doing. Like, in a nutshell, having a secondary stack or having some kind of stack protection or any language built in feature to prevent buffer overflows is not even that important, because the are far larger issues that could lead to bigger security issues, specially considering the fact that the buffer overflows that are incredibly dangerous could have been prevented with a basic level of understanding of how a computer works. In any case, let's focus more on another thing that is wrong with your comment. Who says that a buffer overflow is not dangerous in a game? Have you never heard of games with bugs that allow for remote code execution? If you really think that a bug in a game cannot be critical, you are pretty much out of touch with real software development. There are segments of the industry where it is a matter of ethics to make sure that every security mechanism possible is used. Videogames are one of them. But you seem to confuse the idea that in some of the systems and areas that you listed, it's not just a matter of ethics, it's a matter of necessity. Or do does a safety critical system failing and getting a bunch of people injured (or worse) matter to you that little? Obviously that is not the case, it is clear you are concerned, but you are misguided to think that videogames are not exploitable in a way such that you could do a lot of harm. Cue in some notable examples that I can currently name out of the top of my head... Minecraft, l4d2, any source engine game, payday 2... and many many more. All games that have had exploits in the past that allowed RCE, some to the point of being capable of accessing any files within the computer's file system. (Out of those only payday 2 goes unpatched to this day btw lol, not that you specifically would care, but I think it's worth pointing out that you are right about one thing... ethics matter a lot. My point being that it should matter in EVERY single industry, and that we should not act like exploits in games could never lead to any real harm.)
@@tiranito2834its pointless to argue with the rust fans. There is only 1 way to do anything, its their way, and if you don't agree then you are wrong.
@@steveoc64 first: what a childish argument. second: "one of the biggest problems of buffer overflows, being the way that literally many linux kernel bugs has allowed people in the past to have priviledge escalation exploits and such" and "the point is that nobody should care about preventing them at the language level because even in languages with 0 protection it is trivial to prevent them if you know what you are doing" both sentences in the same paragraph, just to show how wrong the "devs should know what they are doing" argument is and that it simply doesn't work in real life.
@@tiranito2834 One of the philosophies of Rust is that the programmer isn't perfect and can make mistakes. If you're perfect and never make mistakes, then everybody, including hardcore Rust fans, agrees that Rust isn't the best choice.
ROP is how they are getting around stack protectors. Even with ASLR it makes it harder but once they have a buffer overflow it's just a matter of time.
The feature discussed in the video (shadow stack) is specifically designed to prevent ROP. There's also an endbr64 instruction that helps mitigate buffer overflows that modify indirect jumps and calls.
I wonder if he ever gave Rust a real chance, I keep seeing this memmory management only take like that's all there is to the language, its just wrong, Rust has so many good design decisions its worth more than a face value judgement like this.
rust markets itself as solving a problem that is 100% user error. If the user says they don't make that error then what is the point of looking further? rust may do other things well, but who cares, it's raison d'etre is as silly as motorcycles with seatbelts air bags and training wheels. the answer from many will always be "just don't suck lmao"
THIS! I do agree with jon that buffer overflows are not everything, and they aren't even that critical in non user-facing applications. But Rust does so much more than just fixing memory issues left and right
@@JalaeJust don't suck is great and all but why should I use a tool that makes my life harder ? Just so you van flex on the internet ? To your point though, I care about the other things Rust does, and a bunch of other people do too, you can like it or not but your opinions seems rather ignorant to me.
Maybe you should try to exploit a program with a buffer overflow and shadow/safe stack enabled. There are a huge number of issues that it has nothing to do with. Look at bugs discovered/fixed and ask yourself if it would help. Look at CWE and try to decide which it will help with. You might be surprised.
Lifetimes and borrow checking is useful for all sorts of API design and not just accessing buffers. As an imperfect analogy, consider a feature we take for granted. Imagine programming before and after the invention of interfaces/traits. Sure you can do everything the hard way, and if you don’t care then by all means go ahead (in your own code base, stay away from mine), but it really is a genuinely useful (borderline revolutionary) feature
The problem is that they don't manage lifetime of external things, its the same problem with Managed languages, for example DotNet and P/Invoke boundary on GC. I think the real problem with buffer overruns is the operating system failing at its essential task of protecting one process from interfering with another or the rest of the system. Its not a failure of the environment of the programming language, or of the way memory is managed. (all memory is eventually collected as pages either way when the process crashes)
@@monad_tcp Blow makes a simplification of how buffer overflows work. You don't put your evil code in some other program, it needs to be a part of the data you enter to the buffer¹. Because the stack is a part of the process the OS can only assume it's meant to be used. ¹ Even if the stack is non-executable you can chain multiple return addresses on the stack to do complex executions.
Well... Before interfaces, I guess there were interfaces. Basically, in C, you define a structure that contains a bunch of function pointers. Then, when you want to create an "implementation", you just add this structure into the implementation structure, and set the pointers. This is for example often done when you want people to write plugins for your program. You can even have a struct implementing multiple interfaces using the container_of macro, which is used in the Linux kernel. This macro allows a "method" to find the address of its structure (called self in some languages). So I bet "interfaces" are pretty much as old as assembly language.
@@monad_tcpWhat do you mean, "external" things? Like when Rust calls C code? If that's what you're talking about, then if the reference has a longer lifetime than the function call, then all you need to do is specify that in the extern definition.
@@minitbnn, people like to watch these videos for ideas and entertainment. But seems like both his feeds and this comments section always has its fair share of edgy kids who like arguing things like someone would argue sports.
there is an even simpler thing here, just never use fixed size buffers that can overflow on the stack? this isn't rocket science, its just normal programming. its insanely easy to not make this mistake, i used to get this problem before i know better when i was a child... its like the fuss about memory leaks. like... have you never debugged your allocations? its all crutches for the people who write the garbageware like web browsers and word processors. i don't find rust compelling. i looked at it a little, its ugly and quirky, although the concept is pretty sound. i also find the community and the proponents to be somewhat religious and hyperbolic rather than considered and reasonable.
Rust is just like "most new languages" that Jonathan is talking about at 12m50s. It prevents buffer overflows with array bounds checks. That's not what makes Rust interesting. What makes Rust interesting is preventing use-after-free using lifetimes and the borrow checker. That gets grouped under the same "memory safety" umbrella, but it's quite a different problem.
Nobody cares because most programmers don't know. Not because it's not dangerous. Nobody knowing or caring is exactly why the compiler should enforce it for you. Shadow stack is already bypassable, and even hardware shadow stacks could be vulnerable. Give it a little bit of time. They may have already cracked it. Idk. I don't keep up with it as much.
the language should not enforce or make up for lack of competence. thats why we have all these awful garbage collected or raii convoluted runtime heavy languages. what we need is more people understanding memory and how modern operating systems work so we can move past that and embrace memory arenas and ZII.
@@lilyscarlet2584 Ah, yes, a language should let you overflow a buffer, even though it's not necessary to let that happen, ever, because "skill issue". Lmao.
@@nordgaren2358 its just unnecessary. its such an easy thing to avoid if you write code in such a way that cant fail. allowing the programmer to write code like that and just having these safety checks as a bandaid is a problem. its just patching over a flaw in the design. simple assertions should be more than enough. the only time you need that extra error checking is if you are at the mercy of the operating system which is imperfect and can fail at any time rather than your code which can be perfect and never fail that sits on top. thats also why its important to isolate code that is platform specific and not have so much back and forth between layers as much as possible.
The issues is that the EIP is not the only interesting pointer. You can overwrite variables, function pointers. You can do return to libc attacks. So yeah its not only the EIP. That being said I don't think Rust is the answer.
Damn, people in these comments are really arguing that we shouldn't use seatbelts because they make the car slower and experienced drivers never crash anyways 🤦.
@@tablettablete186 a better analogy would be rust is forcing you to ride a bike with training wheels on which is unnecessary and humiliating. Also they're trying to convince you that you're the opposite gender.
I've tried to explain this to many over the years, but it mostly fell on deaf ears. Rust made these massive ergonomic trade-offs to solve a set of problems that are not even really on the practical developer's list of concerns. Overall, they've created more practical problems for their users than the language actually solves. Experienced developers working for a decade+ in industries like game development pretty quickly realized that Rust didn't buy them nearly enough considering the massive development friction it imposes as a cost. It made the most fundamental engineering mistake - getting the cost / benefit ratio wrong, trading off more important things for (significantly) less important things. Unfortunately, it took in a lot of younger developers by taking advantage of their naivety around buffer overruns etc. as actually being high-priority concerns (they're not) - coupled with younger developer's lack of understanding how all other modern languages already have ways to almost entirely - if not entirely - mitigate the issue in practice.
As a new rust user, I chose this over c++ or c not because "omg buffer overflow scary" but because it has tooling which helps me save time, as opposed to spending time tinkering with one to get it to function (example: cmake). Its almost like returning to using plain old vscode as opposed to sinking hours into tinkering with neovim to get something seemingly as trivial as code completion working.
My main complaint is that his mic level is too high so it sounds likes he's talking through a loudspeaker at a rally. But I love me some grumpy J-Blow rants. And the point about us already having the options to avoid common security vulnerabilities is huge. I think the options on compilers should be set to max safety by default, and let people disable these options as they want, hopefully after understanding why.
We might consider Rust to be not so much a way to make fast code safer, but rather a way to allow dangerous developers to write faster code. Perhaps there is a sizeable class of developers who cannot be trusted to do manual memory management or work with raw pointers, but who can be trusted to write safe Rust (I'm not personally convinced of this yet, but it seems plausible).
Well, studies have shown that at least 99.99% of the programmers can't be "trusted" to do manual memory management. You shouldn't have to base an engineering work based on "trust", errors have to be mitigated when possible. Things have to evolve, and languages aren't excluded from that, if you can have a modern language with no exceptions, no null derreferencing, and so on, it has the same speed and it has a much easier and comprehensive toolchain why wouldn't you want to switch. At the end of the day, having less errors and an easier toolchain means more productivity. I get that most of you don't care about having a software that can crash, but when you work on critical safety systems, like in vehicles, where people can get killed, or medical equipement, you shouldn't be "trusting" stuff, you have to perform many validations to get approvals, validations that are very costly.
I can definitely say that I probably wouldn't have been comfortable writing a program that completely bypasses libc both for startup and systemcalls if not for the confidence that Rust provides.
That's a good take on the question. But then you have things like Go which (according to some legends) was evolved from prior work and adopted by Google for exactly this problem .... get the interns doing useful things quickly, whilst keeping them in a big sandbox. Locking in the corporate style guide and formatting standards into the compiler as well was a genius move to avoid bike shedding
@TheIncredibleAverage Actually, you need to understand what you can do and how memory works to be able to understand what's allowed by default by the compiler, what can be allowed in runtime, with elements like RefCells, and what a safe and unsafe environment are, the lifetime of the variables and so on, so no, it's not limiting your knowledge of memory management, it's trying to make sure you know and can only use safe ways to handle memory and to be conscientious of when you're doing risky things and explicitly allowing them. By doing this, if you later encounter a memory-related error, you can easily trace the code and debug it faster. The problem is that most of you never bothered to try a different language and use it following it's own paradigm, compare the development speed, ease of use, perform some speed and memory metric comparisons, bug ratio analysis and so on, so you just try to defend that doing what you already know it's better because it's more comfortable to you.
We should always default to the safer, less performance options with compilers. Only people who know what they're doing should remove guardrails. I have no idea why this flag is not enabled by default, and ones like it.
Rust's &mut rules in single threaded code adds so much complexity for very little. It prevents deleting a container while iterating over it and I think that's mostly it. It's a shame because they have some of the best tools and syntax, but they took memory safety way too far.
Yes, because buffer overflows are only a problem because of "security", even assuming that's fixable from a security point of view. Memory leaks, double-free, thread-safety, memory corruption, unachievable correctness, and the tons of other things that rust fixes are unimportant... because Mr. Blow, who does't know what `-` does in a web search, thinks that a whole programming language is made to fix one problem only. Did you know that some space missions failed because of memory corruption in software, even though they run Valgrind on everything as part of their standard? Of course not, because you're busy arguing for an archaic programming language. No, Mr. Blow. I wouldn't hire you either. Taking correctness this lightly just means you're a bad programmer.
True, there's a multitude of other problems that Rust addresses, and in C and C++ you'll bump into all of those eventually.. the hard way. Having said this, Rust is no walk in the park either. There's the low hanging fruit like a proper build system, package manager, unit test system, all batteries included stuff. But actually getting to grips with if you've been raised on OO and/or C(++) is not straightforward, because you will need to radically reorganize your entire program structure.. and the borrow checker is pretty stupid and you need to tell it _everything_, whereas the language takes huge strides to facilitate referencing. Which feels schizofrenic. It does solve loads of issues, though.
I know 2 space missions that failed: 1. Failed because of conversion between imperial and metric units. 2. Failed because of some floating point accuracy problem. I do not know others, but there are others. If you see NASA coding standards for C code, they do not even allow heap allocation(malloc and free) and pointers, so no double free, memory leaks or use after free. You car run C code, airplanes run C code, guess you should use a horse or boat for traveling, since now you know that car and airplane software is so unsafe.
You just sound like you watched a bunch of rust videos and formed your opinions off them, that doesnt bode well for you as programmer either. Rust is in no way a Fail-Safe fix to all problems that have ruined space missions.
@@jacksonlevine9236 spare me the bullshit. Rust prevents you from doing the mistakes people do in C and C++, and I've been coding rust for 6 years and C++ for over around 15 years. Did YOU use rust for years? Probably not. You're not the first ignorant person to say nonsense like this. "Rust is not perfect, so it's useless". Stfu! Go learn about the Toyota case when buffer overflow KILLED people due to bad breaks causing acceleration. You guys are so ignorant and stupid it's pathetic. You clang so hard to the only thing you know, and think I'm, and all those in the world adopting rust, will fall for your bullshit. We won't, and I don't hire people who talk like this, and I actively discarded people in interviews who said that they prefer C because it's "faster", which is by 3% on average. Yeah, 3% faster is totally worth security and safety concerns. What a bunch of clowns.
@@lostphysicistdamn YT filtered out your last comment unless you sort by new so they did not see your response. I remember the brake failure mistake. Do you have more of these stories? That's pretty interesting. Also it's kinda funny how C devs have to work so hard to get something like this secure. After code review you would still not know if everything is correct. We solve it at compile time lmao. Then C devs claim our language is too restrictive but they are the ones who restrict themselves with rules like The Power of 10 haha
John is so obsessed with pissing on rust its actually kinda sad. He is smart enough to make Jai, and yet too stubborn to make borrow checker better at its job (i.e. more ergonomic) instead.
HAHAHAHAHAHAHAHHAHAHAHAAHAHAAAA!!! you think your tough huh? one word THE FORCED INDENTATION OF CODE. i have taken out two mission critical applications at the same time in less than 5 seconds i have been training for 3 years. also enterprise grade best practices. your fizzbuzz might be bigger than me, but i know mine is smarter and quicker. my fizzbuzz is 130 kb pure lean code. one keystroke and i'll overflow your buffers.
Rust: the zero day hack waiting to happen because it's either fast or safe; never both. Member the rust webframework that was "sooper fast" just to be exposed as unsafe and have the creator rage-delete it? I member! Instead of ~10x your build and compile time, how about you learn to manage memory yourself? malloc free() OMG SO HARD
Rust just has more pedantic compiler - but you can escalate your c++ compiler warning to errors if you want a faster way to try out rust without porting your whole codebase
"Could ask ChatGPT but it would just make up a year". More truth has never been spoken.
"I'm tired of these hacker news guys whos' claim to fame is writing fizzbuzz 2.0"
LMAO Jon goes go hard XD
FYI (reader, IK JB doesn't read these) yes the dash in google excludes results in the string following the hyphen.
Yeah, I was screaming: "Add double quotes!"
Surprised that you can develop games from a good part of your life then don't know how to use google.
But yeah, as he is developing in his own language, he does not really have to use google to search the documentation...
@@rt1517 Well maybe a true good search engine wouldn't have made that mistake... Oh no... [water in cup starts rippling]
@@rt1517I mean these two things have nothing in common with each other...
The clang documentation says that -mshstk is no longer supported on x86_64 because it didn't actually solve the issue (clang 7 docs have more details)
Yep, and this
How about watching the video?
note that this is because of how x86_64 works, on aarch64 it says the feature is considered production ready. additionally, while mshstk might not be available on x86_64, other mechanisms that work similarly do, like safestack. so the point made in the video still stands
meds
Well "nobody cares" is a bold statement nowadays when more and more people and companies seem to care. He called out Microsoft which started caring after they found out they spend billions of dollars every year on fixing this stuff that "nobody cares" about. Apparently someone does care and they do care enough to want to stop it (and save those billions and do something else with them...). And the reason why is actually simple but big companies had to find out the hard way - opt-in software security does not scale. If the developers are allowed not to do it they will no do it. And as it turns out it is impossible to police it at large scales. And then it costs the company incomprehensible amount of money to fix later. So it is only pragmatic wanting to fix it.
But that is on macro level. What about individual level. Well turns out we are people and even gods of programming like Jon will inevitably make mistakes. It takes just one on a particularly wrong place and big issue is born. Wouldn't it be nice if we had a way not to make such mistakes in the first place... oh. So yeah, I don't buy the argument here as it seems contrary to what he claimes elsewhere (sw is shit nowadays). Well if you bash every way that will (force) it better then don't be surprised it magically does not become better.
Microsoft uses something called SAL which puts enough metadata on the function prototypes so it can be statically checked automatically for buffer and memory management problems.
The thing is having something to do the analysis, having it mandatory in the programming language and compiler is one way of having programmers use it by force. You could try that with C++ and indeed that's what Microsoft does and Microsoft can enforce it via company policy.
The advantage of having the programming language enforce it is that it will work for the rest of the industry, which might not have proper policies to enforce the correct way will also benefit from the checking. Another plus which a new programing language is getting rid of 30 years of accumulated cruft in C++, which is always a win.
The disadvantage is needing to rewrite code.
And yet Microsoft's product quality gets worse and worse every year.
Stack cookies (a different security mitigation than shadow stacks) are enabled by default in MSVC.
8:56 Shadow stacks do have hardware support as of Intel 11th gen (so-called CET). Adoption has been underway but is not the default yet.
While I'm sure I'm nowhere as good a programmer blow is, I really don't get his completely nuance-less takes on these things. Not even a rust fanboy or anything, but "uhhh who cares, all these issues are trivial for a Nietzschean ubermensch 10X giga programmer" take is always so stupid. Even as shit as trends in software are, many appear for a very good reason, especially in this case. No matter how perfect you are, other people for the most part are rеtarded, so you'd think it would make sense to not let them blow their foot off and yours by proxy when you have to work in any codebase your divine mind has not produced from scratch
I think he is mostly referring to gaming industry. No one in the gaming industry give AF about security on client side.
If you are an engineer working on nuclear reactors, stuff wil be hard, you will need a lot of training, checks, security, ... but the work is hard and you will have to make it good or face a nuclear incident. In software engineering? It doesn't matter, incompetence is fine because we're used to "oh the program crashed". Why don't we have the same level of standard in a field that is used by a vast majority of the population, that our whole society now depends on?
@@sumofat4994games are the most stiched toguether bug rithen piece of software in existence.
You can't control the code you don't write.
Not true if it's open source or you have a license to the proprietary code or you're a sufficiently large customer.
The issue is shadow stack is part of intel CET was promptly defeated anyway (look up mcaffee paper on this), and the cost is non-trivial. I looked up some papers, and they showed a case 10^7 magnitude slow down with a fully CET compiled program. Amd's solution is apparently even weaker :/
I asked a cybersec guy and he said it's because the perf tradeoff isn't worth it
what about something like safestack? the clang documentation says the impact on performance is less than .1 percent on average
@@knufyeinundzwanzig2004 I promise you much smarter people than me have looked into this and determined it's not worth it. Safestack is even less safe and has been pwned with like a 30 asm instruction demo iirc?
So, Jon just skill issue'd us.
My experience is that the code is usually written by monkeys who will twist every little language feature into a monster, slow and full of bugs.
The whole Frontend world invented massive guard rails (e.g. React) specifically to counter this, it's been working alright so far (if you disagree, go to jQuery times for a moment).
I feel that we need similar stuff on a system programming side. I mean, we've had types for a half a century now. We now need more innovations.
Jon is right that most of us don't even try, but Jon is wrong because we will not try unless forced. You don't measure others efficiency by your own. Compiler flags are cool but useless because they are optional. We need more sensible defaults.
People don't bother because it's incredibly tedious to intently put every buffer at a specific memory arena location. Most programs don't preallocate memory, lots of developers don't care or know enough to use a shadow stack or run sanitizers. So it is an issue because people generally don't follow the best practices all the time and that causes issues, so I think it's good that the compiler is the jerk that politely yells at them to do so (by default).
And educating your devs on the matter, making sure they care is easier than teaching them a new programming language that forces it on them (also rewrite your program in Rust)
@@edhahaz Making sure they care doesn't solve the problem, statistics proff that.
Also, you don't have to rewrite your code using Rust, you can develop new modules in Rust and integrate existing C and C++ code into the same system, it works really well
If it’s too hard to get people to turn on a compiler flag they’re really not going to be happy learning a new language. Especially a language like Rust that has a steep learning curve and is very un C-like. Lazy Rust programmers are still going to create bugs, just of a different sort.
Almost every c programmer or c++ programmer has their own abstraction over creating buffers memory arenas etc... its trivial stop those kinds of buffer overflow accesses or out of bounds errors.
@@ALIENdrifter66 New system languages should be easier and faster to develop with not slower and harder so Rust for game dev is a big fat L. For other security critical areas its fine as long as you dont care how long it takes.
Death by a thousand cuts is a well-known idiom. Sometimes we leave dead code around for months at a time. Sometimes we can't hire someone working at $200k salaries who know all the ins and outs of handling a knife with a duct-taped handle. Sometimes old-ass languages are stuffed with committee that don't have the time or mental flexibility to ascertain that a major, backwards-incompatible version bump can be a good thing.
I can't even tell if this should even be a rant about Rust, as much as it is about older languages that haven't polished themselves or their tooling around blatant, well-known issues. We clutch our pearls over the need to read every book about the C standard and the ins and outs of a compiler just to make a goddamn GUI app or simple videogame. Why is it supposed to be more complicated than installing the compiler and writing your program? The compiler is literally looking at your code. Books can't look at your code. People don't want to look at your code. Looking at your own code is often repulsing in hindsight.
Frankly, online software culture fucking sucks as a whole, and I don't know if it'll ever change, regardless of who makes whatever language do whatever.
Did chatGPT write this in hate-mode?
@@rrw00 Longform rant = Chat GPT. Media literacy is dead and the general population is fucked.
It was only a joke, don't beat yourself up over it. :) @@j-wenning
Rust chuds = Skill issue
"You shouldn't have to read the entire C standard"
I also don't wanna read the entire rust book, you gotta choose one though
I know a lot of people who've made a decent amount from this bug which no one cares about.
I read an explanation on stack overflow about how you should never use system() because of security issues. I went and researched the potential dangers of using system(), and immediately began using it again.
Yeah people are insane... it almost always seems to be the linux/haskell/Rust/hacker news people as well.
I'm not saying everyone who uses these things is crazy... just that they seem to attract crazy.
*replaces your favorite programming language with a compiler flag*
“Nothin’ personnel kid”
It's spelled personal.
@@seriouscat2231 cringe
@@jamesevans2507, I think it was just funny.
I prefer to believe it was misspelled intentionally.
@@jamesevans2507, as far as I a concerned, only chronically online teenagers use that word unironically.
Summarizing analogy. Hopefully close enough representation of his position
Imagine there is a dangerous bridge with no guard rails. We've known about how to build and apply guard rails for years, but for some reason nobody does. It's stupid and yes we should put up guard rails, but cars driving off the edge is apparently rare enough nobody cares. Yes you could rebuild the entire bridge so that cars slot into a rails system and it is impossible for them to steer incorrectly, and that would be a lot safer, but why bother replacing the whole thing when we could just do the guard rails.
I think he's also implying that there are other problems, more significant than the guard rails, that we prioritized in the past, discarding buffer overflows as something trivially solvable. But now because of Rust, we are overblowing the problem of the guard rails and potentially ignoring other things that might be more important. In other words - bike shedding. Spending more time thinking about how the bikes need to be kept safe than building the damn nuclear power plant. (I don't necessarily agree with him but I think that's what he is implying)
Nice
Except companies like Microsoft and Google spend millions of dollars every year digging cars out of the canyon.
Perhaps the big influencers in the compiler world never really wanted to protect from buffer overflows, because then how else would the intelligence agencies be able to backdoor damn near everything?
The "nobody gives a shit about buffer overflows" approach and "just write better code" advice is a misguided bad take.
If you're a bad programmer, sure
Hint: think through the logic of your code, check if there is the possibility of a memory leak anywhere.
@@slynt_ is that before or after you work out if the program halts or not?
@@Alex-qq1gm You realise that there is a large subset of all possible programs (this subset includes all the ones you would ever actually use for any practical purpose) for which it is deterministic whether they halt or not, right? And that the halting problem is pretty much only of theoretical interest because of that fact?
Well, memory leaks are even better than that, because if you understand the logic of your code correctly, you will identify memory leaks 100% of the time. So just make sure you know what you are telling the computer to do, and you won't have a problem!
@@slynt_you're arguing with a person who looks like a manager.
Value your time more
@@slynt_ bad programmers are going to write code. Your "just think harder" solution doesn't help them, or anyone that has to work with them. If you had spent 5 seconds actually thinking about the problem we are trying to solve you'd realise that.
12:00 C++20 has std::span, which are just like passing references to arrays in other languages. In fact your IDE was just giving a warning to use it.
there is also gsl::span for those on previous versions of C++
I know people are going to kill me over this but... isn't span the same concept as a fat pointer?
I have been working more on C++ than other languages but I still don't understand it because I find it an incredibly frustrating language.
@@MrAntraxico AFAIK there are multiple kinds of fat pointers, e.g. when it comes to dynamic dispatch, a fat pointer would have pointers to both the data and the virtual table (normal C++ pointers are always "thin" and the virtual table pointer is stored within the dynamic object), and that is quite different from a span, which is just a slice/view of continuous data
That's grand. But now if you use it your code is less readible and any old coder will come along and complain about you using a feature he had to look up.
I'd rather separate from these people in the beginning, that way they know "uh, he's using rust, he's a hopeless cause" and I have peace of mind in being able to use all the fancy new features without having to justify myself to anyone - or at least being afraid of having to do that - , because you know what, they're all on by default.
Also, correct me if I'm wrong, but I think spans are not yet supported in clang. If that's the feature I remembered and wanted to use in some C++ code, only to realize it wasn't possible. I wanted to reduce the ridiculous length of for loop headers, caused by me wanting to give the running variables speaking names, combined with the fact that you'll need to mention the running variable 3 fucking times in the header.
>uses 16 by 10 monitor
>puts taskbar on the left
ah yes
You don't know left from right.
Taskbar on the left (the real one) is best for wrist health, also because monitors are wider than they are tall.
@@drivers99 i.. thanks
I think Jon meant that nobody decent cares about this problem, not actually 'everyone'. Obviously most of you can't program so you care about trivial problem and Jon knows that
I'm surprised he didn't mention heap-related security bugs, since those are much harder to fix and where Rust is unique compared to other modern langs. Most memory-safe langs do it with garbage collection or reference counting, but Rust does it at compile-time with the borrow checker, leading to the same safety with C-level performance.
...until malware is embedded in the Rust compiler and distributed to Rust developers who don't understand what that entails.
You guys do understand that happens right? If you do, then great, but what about all the other Rust devs? Malware is probably already pouring into that community, and the bigger it gets, the more likely it will become a target.
Do you know how to find out if your compiler is safe? If you don't, then you are vulnerable. That doesn't mean that we can only use JIT compiled langs like Python... because they are vulnerable too... one language is NOT going to solve this problem with just a compiler.
Package managers create far more vulnerabilities than manually acquiring libraries, so does that mean we shouldn't use them? What about browsers?
I'm sick of this idea that Rust fixes everything. It doesn't... developers need to step up and learn about security if they care about it. Stop leaving it to the compiler, or the language, or whatever else you place your faith in.
@@malusmundus-9605 When has malware been embedded into a complier? I know the "reflections on trusting trust" attack is theoretically possible and there was a demo of it, but I don't know of any cases of it being applied in practice. Unfortunately, no language is immune from it unless it has a fully documented and reproducible bootstrap chain, which is very hard to do and likely requires lots of custom hardware, since malicious hardware is theoretically possible too. But it's, very unlikely any popular compilers are infected, IMO.
Slightly worse performance than C, at least according to an academic paper I read in college
what about memory arenas. you dont need raii or gc just combine the lifetimes of things that go together and use scratch space. that trivializes 99% of cases.
@@malusmundus-9605LOL Are you good? My guy we have a language that solves a problem and all you have to say about is "but it does not solve THIS other problem" which no language can solve. Maybe u need meds 🤡
I'm sorry, I know he's great, and whatnot, but he comes across as uninformed on the issue, it's just hand-waving... "Yeah, no, it was fixed in the nineties. I just don't remember how, when, or anything, really, but trust me, it's trivial to fix, and the fix is great... but for some reason it's not on by default, but I'm sure that's not relevant to my rant, at all".
you dont need the language to protect you from buffer overflows its about writing code that cant fail in a language that gives control like c. memory safety is not a language feature is the point.
Jon's opinions on Rust always seem based on the reality of game dev exclusively, but he never actually makes this distinction. Yeah, no one cares about buffer overflows in a video game. But what about OSs? Drivers? Critical embedded stuff? There are segments of the industry where it's a matter of *ethics* to make sure every security mechanism possible is used.
Well, there's a lot to unpack here...
First, if you had listened for more than 2 minutes you would know that you are wrong about that statement regarding Jon... He literally brings in about 1 and a half minutes in one of the biggest problems of buffer overflows, being the way that literally many linux kernel bugs has allowed people in the past to have priviledge escalation exploits and such... so it shows he knows what he's talking about, and cares. His point is not that we should not care about buffer overflows, the point is that nobody should care about preventing them at the language level because even in languages with 0 protection it is trivial to prevent them if you know what you are doing. Like, in a nutshell, having a secondary stack or having some kind of stack protection or any language built in feature to prevent buffer overflows is not even that important, because the are far larger issues that could lead to bigger security issues, specially considering the fact that the buffer overflows that are incredibly dangerous could have been prevented with a basic level of understanding of how a computer works.
In any case, let's focus more on another thing that is wrong with your comment. Who says that a buffer overflow is not dangerous in a game? Have you never heard of games with bugs that allow for remote code execution? If you really think that a bug in a game cannot be critical, you are pretty much out of touch with real software development. There are segments of the industry where it is a matter of ethics to make sure that every security mechanism possible is used. Videogames are one of them. But you seem to confuse the idea that in some of the systems and areas that you listed, it's not just a matter of ethics, it's a matter of necessity. Or do does a safety critical system failing and getting a bunch of people injured (or worse) matter to you that little? Obviously that is not the case, it is clear you are concerned, but you are misguided to think that videogames are not exploitable in a way such that you could do a lot of harm.
Cue in some notable examples that I can currently name out of the top of my head... Minecraft, l4d2, any source engine game, payday 2... and many many more. All games that have had exploits in the past that allowed RCE, some to the point of being capable of accessing any files within the computer's file system. (Out of those only payday 2 goes unpatched to this day btw lol, not that you specifically would care, but I think it's worth pointing out that you are right about one thing... ethics matter a lot. My point being that it should matter in EVERY single industry, and that we should not act like exploits in games could never lead to any real harm.)
He literally addressed this in the first 2 mins of the video.
@@tiranito2834its pointless to argue with the rust fans. There is only 1 way to do anything, its their way, and if you don't agree then you are wrong.
@@steveoc64 first: what a childish argument.
second: "one of the biggest problems of buffer overflows, being the way that literally many linux kernel bugs has allowed people in the past to have priviledge escalation exploits and such" and "the point is that nobody should care about preventing them at the language level because even in languages with 0 protection it is trivial to prevent them if you know what you are doing" both sentences in the same paragraph, just to show how wrong the "devs should know what they are doing" argument is and that it simply doesn't work in real life.
@@tiranito2834 One of the philosophies of Rust is that the programmer isn't perfect and can make mistakes. If you're perfect and never make mistakes, then everybody, including hardcore Rust fans, agrees that Rust isn't the best choice.
ROP is how they are getting around stack protectors. Even with ASLR it makes it harder but once they have a buffer overflow it's just a matter of time.
The feature discussed in the video (shadow stack) is specifically designed to prevent ROP. There's also an endbr64 instruction that helps mitigate buffer overflows that modify indirect jumps and calls.
the only possibility to go around shadow stacks would be overwriting function pointers or finding string format attacks
"You would not hire me? - I would not hire you!" LMAO absolutely BTFO
I wonder if he ever gave Rust a real chance, I keep seeing this memmory management only take like that's all there is to the language, its just wrong, Rust has so many good design decisions its worth more than a face value judgement like this.
rust markets itself as solving a problem that is 100% user error. If the user says they don't make that error then what is the point of looking further? rust may do other things well, but who cares, it's raison d'etre is as silly as motorcycles with seatbelts air bags and training wheels. the answer from many will always be "just don't suck lmao"
THIS! I do agree with jon that buffer overflows are not everything, and they aren't even that critical in non user-facing applications. But Rust does so much more than just fixing memory issues left and right
Rust has many great things but the borrow checker is the main thing, and if someone doesn't like the borrow checker it's a deal-breaker.
@@JalaeJust don't suck is great and all but why should I use a tool that makes my life harder ? Just so you van flex on the internet ? To your point though, I care about the other things Rust does, and a bunch of other people do too, you can like it or not but your opinions seems rather ignorant to me.
@@aenpien Its not the main thing, is the one that stands out the most because you have to deal with it all the time.
04:30 "-whatever" means "excluding results containing" lolz
Maybe you should try to exploit a program with a buffer overflow and shadow/safe stack enabled. There are a huge number of issues that it has nothing to do with. Look at bugs discovered/fixed and ask yourself if it would help. Look at CWE and try to decide which it will help with. You might be surprised.
Lifetimes and borrow checking is useful for all sorts of API design and not just accessing buffers.
As an imperfect analogy, consider a feature we take for granted. Imagine programming before and after the invention of interfaces/traits. Sure you can do everything the hard way, and if you don’t care then by all means go ahead (in your own code base, stay away from mine), but it really is a genuinely useful (borderline revolutionary) feature
The problem is that they don't manage lifetime of external things, its the same problem with Managed languages, for example DotNet and P/Invoke boundary on GC.
I think the real problem with buffer overruns is the operating system failing at its essential task of protecting one process from interfering with another or the rest of the system. Its not a failure of the environment of the programming language, or of the way memory is managed. (all memory is eventually collected as pages either way when the process crashes)
@@monad_tcp Blow makes a simplification of how buffer overflows work. You don't put your evil code in some other program, it needs to be a part of the data you enter to the buffer¹. Because the stack is a part of the process the OS can only assume it's meant to be used.
¹ Even if the stack is non-executable you can chain multiple return addresses on the stack to do complex executions.
Well... Before interfaces, I guess there were interfaces. Basically, in C, you define a structure that contains a bunch of function pointers. Then, when you want to create an "implementation", you just add this structure into the implementation structure, and set the pointers.
This is for example often done when you want people to write plugins for your program.
You can even have a struct implementing multiple interfaces using the container_of macro, which is used in the Linux kernel.
This macro allows a "method" to find the address of its structure (called self in some languages).
So I bet "interfaces" are pretty much as old as assembly language.
@@monad_tcpWhat do you mean, "external" things? Like when Rust calls C code? If that's what you're talking about, then if the reference has a longer lifetime than the function call, then all you need to do is specify that in the extern definition.
Shadow stack seems to be GCC 12 (2022)
"Buffer overflow does not matter."
Ask Ariane Space.
Lollercoaster
Don't a bunch of CVE's depend on this? You'd think Shadow Stack would be more popular
Why fix it? If none bothers to do it manually then let it be fixed under the hood
These Jon Blow hot take clips attract terrible programmers like like light does moths
You one of them?
@@minitbnn, people like to watch these videos for ideas and entertainment. But seems like both his feeds and this comments section always has its fair share of edgy kids who like arguing things like someone would argue sports.
The Dark Blow channel
there is an even simpler thing here, just never use fixed size buffers that can overflow on the stack? this isn't rocket science, its just normal programming. its insanely easy to not make this mistake, i used to get this problem before i know better when i was a child...
its like the fuss about memory leaks. like... have you never debugged your allocations?
its all crutches for the people who write the garbageware like web browsers and word processors.
i don't find rust compelling. i looked at it a little, its ugly and quirky, although the concept is pretty sound. i also find the community and the proponents to be somewhat religious and hyperbolic rather than considered and reasonable.
Rust is just like "most new languages" that Jonathan is talking about at 12m50s. It prevents buffer overflows with array bounds checks. That's not what makes Rust interesting. What makes Rust interesting is preventing use-after-free using lifetimes and the borrow checker. That gets grouped under the same "memory safety" umbrella, but it's quite a different problem.
blow is a loudmouth who regularly speaks beyond his ken
Nobody cares because most programmers don't know. Not because it's not dangerous.
Nobody knowing or caring is exactly why the compiler should enforce it for you.
Shadow stack is already bypassable, and even hardware shadow stacks could be vulnerable. Give it a little bit of time. They may have already cracked it. Idk. I don't keep up with it as much.
the language should not enforce or make up for lack of competence. thats why we have all these awful garbage collected or raii convoluted runtime heavy languages. what we need is more people understanding memory and how modern operating systems work so we can move past that and embrace memory arenas and ZII.
@@lilyscarlet2584 Rust does just fine. And yes, the language should keep you from doing something stupid. This is an L take.
@@nordgaren2358 only if you are bad at programming. this mentality is why software today sucks.
@@lilyscarlet2584 Ah, yes, a language should let you overflow a buffer, even though it's not necessary to let that happen, ever, because "skill issue".
Lmao.
@@nordgaren2358 its just unnecessary. its such an easy thing to avoid if you write code in such a way that cant fail. allowing the programmer to write code like that and just having these safety checks as a bandaid is a problem. its just patching over a flaw in the design. simple assertions should be more than enough. the only time you need that extra error checking is if you are at the mercy of the operating system which is imperfect and can fail at any time rather than your code which can be perfect and never fail that sits on top. thats also why its important to isolate code that is platform specific and not have so much back and forth between layers as much as possible.
The issues is that the EIP is not the only interesting pointer. You can overwrite variables, function pointers. You can do return to libc attacks. So yeah its not only the EIP. That being said I don't think Rust is the answer.
Guess what happens when you call a function pointer? It changes the instruction pointer. Same for returning to libc.
Damn, people in these comments are really arguing that we shouldn't use seatbelts because they make the car slower and experienced drivers never crash anyways 🤦.
I am stealing that analogy, it's perfect! lol
@@tablettablete186it's not even close
@@rusi6219 Can you explain?
@@tablettablete186 a better analogy would be rust is forcing you to ride a bike with training wheels on which is unnecessary and humiliating. Also they're trying to convince you that you're the opposite gender.
Or put all your buffers on the heap.
🤡💀
I want to be free
It doesn't matter, never pass pointers, always pass a struct with a pointer and the length of the buffer, then you check the length.
That prevents things like overrunning into code. It does not prevent reading and writing things you shouldn't. See: heartbleed.
@@exciting-burp Indeed. But same as the 2nd stack.
Criticizing Rust is good. Criticizing Rust by focusing exclusively on "eliminate buffer overflows" is less good.
I've tried to explain this to many over the years, but it mostly fell on deaf ears.
Rust made these massive ergonomic trade-offs to solve a set of problems that are not even really on the practical developer's list of concerns. Overall, they've created more practical problems for their users than the language actually solves.
Experienced developers working for a decade+ in industries like game development pretty quickly realized that Rust didn't buy them nearly enough considering the massive development friction it imposes as a cost.
It made the most fundamental engineering mistake - getting the cost / benefit ratio wrong, trading off more important things for (significantly) less important things.
Unfortunately, it took in a lot of younger developers by taking advantage of their naivety around buffer overruns etc. as actually being high-priority concerns (they're not) - coupled with younger developer's lack of understanding how all other modern languages already have ways to almost entirely - if not entirely - mitigate the issue in practice.
As a new rust user, I chose this over c++ or c not because "omg buffer overflow scary" but because it has tooling which helps me save time, as opposed to spending time tinkering with one to get it to function (example: cmake). Its almost like returning to using plain old vscode as opposed to sinking hours into tinkering with neovim to get something seemingly as trivial as code completion working.
My main complaint is that his mic level is too high so it sounds likes he's talking through a loudspeaker at a rally. But I love me some grumpy J-Blow rants. And the point about us already having the options to avoid common security vulnerabilities is huge. I think the options on compilers should be set to max safety by default, and let people disable these options as they want, hopefully after understanding why.
We might consider Rust to be not so much a way to make fast code safer, but rather a way to allow dangerous developers to write faster code. Perhaps there is a sizeable class of developers who cannot be trusted to do manual memory management or work with raw pointers, but who can be trusted to write safe Rust (I'm not personally convinced of this yet, but it seems plausible).
Well, studies have shown that at least 99.99% of the programmers can't be "trusted" to do manual memory management. You shouldn't have to base an engineering work based on "trust", errors have to be mitigated when possible.
Things have to evolve, and languages aren't excluded from that, if you can have a modern language with no exceptions, no null derreferencing, and so on, it has the same speed and it has a much easier and comprehensive toolchain why wouldn't you want to switch.
At the end of the day, having less errors and an easier toolchain means more productivity.
I get that most of you don't care about having a software that can crash, but when you work on critical safety systems, like in vehicles, where people can get killed, or medical equipement, you shouldn't be "trusting" stuff, you have to perform many validations to get approvals, validations that are very costly.
I can definitely say that I probably wouldn't have been comfortable writing a program that completely bypasses libc both for startup and systemcalls if not for the confidence that Rust provides.
That's a good take on the question. But then you have things like Go which (according to some legends) was evolved from prior work and adopted by Google for exactly this problem .... get the interns doing useful things quickly, whilst keeping them in a big sandbox. Locking in the corporate style guide and formatting standards into the compiler as well was a genius move to avoid bike shedding
@TheIncredibleAverage Actually, you need to understand what you can do and how memory works to be able to understand what's allowed by default by the compiler, what can be allowed in runtime, with elements like RefCells, and what a safe and unsafe environment are, the lifetime of the variables and so on, so no, it's not limiting your knowledge of memory management, it's trying to make sure you know and can only use safe ways to handle memory and to be conscientious of when you're doing risky things and explicitly allowing them. By doing this, if you later encounter a memory-related error, you can easily trace the code and debug it faster.
The problem is that most of you never bothered to try a different language and use it following it's own paradigm, compare the development speed, ease of use, perform some speed and memory metric comparisons, bug ratio analysis and so on, so you just try to defend that doing what you already know it's better because it's more comfortable to you.
@TheIncredibleAverage I think learning Rust makes you a better C++ programmer. The things that Rust forces you to do are just best practice in C++.
Is he senior in react though?
Ya, React is the only programming language anyone needs to know.
I thought chatGPT prompting was the only language anyone needed to know.@@samjohns8381
We should always default to the safer, less performance options with compilers. Only people who know what they're doing should remove guardrails. I have no idea why this flag is not enabled by default, and ones like it.
I was going to watch this, but clicked on a batshit interview this guy gave about open source software first. Nah man.
Rust's &mut rules in single threaded code adds so much complexity for very little. It prevents deleting a container while iterating over it and I think that's mostly it. It's a shame because they have some of the best tools and syntax, but they took memory safety way too far.
exactly. and the fact that lifetimes are part of the type ruined the lanugage imo
My guy we have functions for deleting while iterating over vec lmao
@@hamed9327Lifetimes being part of the type is the reason why Rust guarantees temporal memory safety. I don't think it can be designed any better.
[mouth sounds]
Yes, because buffer overflows are only a problem because of "security", even assuming that's fixable from a security point of view. Memory leaks, double-free, thread-safety, memory corruption, unachievable correctness, and the tons of other things that rust fixes are unimportant... because Mr. Blow, who does't know what `-` does in a web search, thinks that a whole programming language is made to fix one problem only.
Did you know that some space missions failed because of memory corruption in software, even though they run Valgrind on everything as part of their standard? Of course not, because you're busy arguing for an archaic programming language.
No, Mr. Blow. I wouldn't hire you either. Taking correctness this lightly just means you're a bad programmer.
True, there's a multitude of other problems that Rust addresses, and in C and C++ you'll bump into all of those eventually.. the hard way. Having said this, Rust is no walk in the park either. There's the low hanging fruit like a proper build system, package manager, unit test system, all batteries included stuff. But actually getting to grips with if you've been raised on OO and/or C(++) is not straightforward, because you will need to radically reorganize your entire program structure.. and the borrow checker is pretty stupid and you need to tell it _everything_, whereas the language takes huge strides to facilitate referencing. Which feels schizofrenic. It does solve loads of issues, though.
I know 2 space missions that failed:
1. Failed because of conversion between imperial and metric units.
2. Failed because of some floating point accuracy problem.
I do not know others, but there are others.
If you see NASA coding standards for C code, they do not even allow heap allocation(malloc and free) and pointers, so no double free, memory leaks or use after free.
You car run C code, airplanes run C code, guess you should use a horse or boat for traveling, since now you know that car and airplane software is so unsafe.
You just sound like you watched a bunch of rust videos and formed your opinions off them, that doesnt bode well for you as programmer either. Rust is in no way a Fail-Safe fix to all problems that have ruined space missions.
@@jacksonlevine9236 spare me the bullshit. Rust prevents you from doing the mistakes people do in C and C++, and I've been coding rust for 6 years and C++ for over around 15 years. Did YOU use rust for years? Probably not. You're not the first ignorant person to say nonsense like this. "Rust is not perfect, so it's useless". Stfu!
Go learn about the Toyota case when buffer overflow KILLED people due to bad breaks causing acceleration. You guys are so ignorant and stupid it's pathetic. You clang so hard to the only thing you know, and think I'm, and all those in the world adopting rust, will fall for your bullshit. We won't, and I don't hire people who talk like this, and I actively discarded people in interviews who said that they prefer C because it's "faster", which is by 3% on average. Yeah, 3% faster is totally worth security and safety concerns. What a bunch of clowns.
@@lostphysicistdamn YT filtered out your last comment unless you sort by new so they did not see your response. I remember the brake failure mistake. Do you have more of these stories? That's pretty interesting. Also it's kinda funny how C devs have to work so hard to get something like this secure. After code review you would still not know if everything is correct. We solve it at compile time lmao. Then C devs claim our language is too restrictive but they are the ones who restrict themselves with rules like The Power of 10 haha
How dare you suggest Microsoft'ies aren't the best programmers!
at this point it's unclear to me how anyone could have faith in anything micro$oft does
"Nobody gives a shit"
Oh rly? And what about this? CVE-2021-3156
Time to stop reading HackerNews, I guess :)
This guy seems very knowledgeable but lacks some ethics
Great video btw!
What
John is so obsessed with pissing on rust its actually kinda sad. He is smart enough to make Jai, and yet too stubborn to make borrow checker better at its job (i.e. more ergonomic) instead.
C++ had all these safety issues solved in c++11.
WHO the FUCK is Jonathan Blow and WHY do I keep getting recommended his opinions? I DONT CARE
Your momma
hit the 3 dots and select "don't recommend" and take yourself elsewhere
Buffer overflows are the climate change we need to be protected from by creating more CO2 using memory bloating and CPU wasting techniques.
lmao and dont forget the wasted amount of resources for triaging and fixing bug reports + the wasted amount of money for bug bounty payouts 😆
@@RustIsWinning So Rust shills will be put in Siberian re education camps if they are responsible for a bug?
HAHAHAHAHAHAHAHHAHAHAHAAHAHAAAA!!!
you think your tough huh?
one word THE FORCED INDENTATION OF CODE.
i have taken out two mission critical applications at the same time in less than 5 seconds i have been training for 3 years.
also enterprise grade best practices.
your fizzbuzz might be bigger than me, but i know mine is smarter and quicker.
my fizzbuzz is 130 kb pure lean code.
one keystroke and i'll overflow your buffers.
Found the script kiddie xD
wikipedia has a good history of buffer overflow protection. en.wikipedia.org/wiki/Buffer_overflow_protection
Rust: the zero day hack waiting to happen because it's either fast or safe; never both. Member the rust webframework that was "sooper fast" just to be exposed as unsafe and have the creator rage-delete it? I member!
Instead of ~10x your build and compile time, how about you learn to manage memory yourself?
malloc
free()
OMG SO HARD
Rustranies are script kiddies who've never heard about arenas or compiler flags or really anything
Two 🤡🤡
Says the guy who accidentally does:
free()
free()
Oops
Rust just has more pedantic compiler - but you can escalate your c++ compiler warning to errors if you want a faster way to try out rust without porting your whole codebase
“Thanks, I hate it”
Bait used to be believable