5 ms·

In C, we made clear in C23 that there is no true time-travel UB and have eliminated about 30% of UB in the core language for C2Y as part of an ongoing effort th

by uecker 2y ago

In C, we made clear in C23 that there is no true time-travel UB and have eliminated about 30% of UB in the core language for C2Y as part of an ongoing effort that will eliminate most of the simple cases of UB. We also have plans to add opt-in memory safety mode proving full spatial and temporal memory safety. Having said this, I think the sudden and almost exclusive focus on memory safety is weird. As a long-term Linux user, this is not my main problem. This is what people building app stores and non-free content distribution systems need and they now re-engineer the world according to their needs. There are lot of things compromising my online safety and freedom, and certainly memory safety issues are not very high on this list. Finally, what Rust achieves, and what a memory-safe mode in C will hopefully also achieve in the future, is also just an incremental improvement. As long as there in unsafe code, and in practice there will be a lot of unsafe code, there is no perfect memory safety.

Sharlin 2y ago
I’m not sure how you can even try to juxtapose technical issues like memory safety with sociopolitical problems like corpo interests being in conflict with the interests of the common people. The formeer can be alleviated with technical solutions. There’s nothing that a programming language can do about the latter. Also, I question your claim that memory unsafety is not of great importance to regular computer users. Perhaps not if your computer is airgapped from the internet and never gets any unvetted software installed. Otherwise, have you missed the primary cause of the majority of CVEs issued in the past decades? Do you not think that the main technical problem behind countless security vulnerabilities, that have very concretely affected tens and hundreds of millions of people, does not deserve the attention that it’s finally starting to get? Google has reported that the mere act of stopping writing new code in memory-unsafe languages has made the fraction of mem safety vulnerabilities drop from >80% to ~20% in a few years. This is because bugs have a half-life, and once you stop introducing new bugs, the total count starts going down asymptotically as existing bugs get fixed. Finally, since you inevitably mentioned Rust, memory safety is indeed a necessary but not sufficient condition in software reliability. Luckily, Rust also happens to greatly decrease the odds of logic bugs getting in, thanks to its modern (i.e. features first introduced in ML in the 70s) type system that actually tries to help you get things right. C is never going to have those parts, the “if it compiles, it is correct by construction” assurance. C++ has janky, half-assed, non-orthogonal, poorly-composing, inconsistently designed versions of a lot of the stuff, but it also has all of the cruft, and that cruft is still what is taught to people before the less-bad parts. And because C++ is larger than the most people’s brain capacity, most people can’t even get to the more less-bad parts, never mind keeping up with new standard versions.
- uecker 2y ago
  Technology and society are never separate things. The question if why something is seen as important or not, and what is funded, very much depends on societal questions. I am using Linux for almost 30 years. I have never been hacked, or know anybody personally, who was hacked because of a memory safety issue in any open-source component. I know such people and companies exist, I just know many more which are affected by other issues. I know many people affected by bugs in Microsoft software, including myself. I am also affected by websites spying on me, from email not being encrypted by default, etc. A lot of things could be done do make my safety and security better. That you cite Google actually demonstrates the problem: Memory safety is much more their concern, not mine. And C definitely will have memory safety. Stay tuned. (And I also like to have memory safety.) I do not care about C++ nor do I care about Rust. Both languages are far too complex for my taste.
- bluGill 2y ago
  > Otherwise, have you missed the primary cause of the majority of CVEs issued in the past decades Only because CVEs are never issued when humans are compromised. While that is probably the correct action on their part it means your argument is flawed as you don't account for human vulnerabilities which are much more common. Yes memory safety is a big problem and we should do something - but as an industry we need to not ignore the largest problem. There is a lot we can do in UX to prevent most security vulnerabilities, and putting too much emphasis on memory can take away from potentially more productive paths.
galangalalgol 2y ago
Can you clarify why memory safety isn't your main problem? Do you just mean that UB isn't your biggest problem, or that memory safety isn't your biggest source of UB? The latter sounds unlikely, and the former is interesting as all the code I give away for free gets used by people who very much care if it has UB.
- uecker 2y ago
  When we talk to companies that are in the business of helping other companies that were hacked, the stories we hear are never that they were hacked by some 0-day in the Linux kernel or a server software caused by some memory-safety issue. Instead, they are hacked because some did not install updates of some component on the webserver, password authentication was used, the same passwords are used on different servers, etc. or some bug in some overly complex Microsoft infrastructure part.
  - lelanthran 2y ago
    > Instead, they are hacked because some did not install updates of some component on the webserver, password authentication was used, the same passwords are used on different servers, etc. or some bug in some overly complex Microsoft infrastructure part. Last I checked (a few months ago) 8 out of 10 breaches were due to human error. As far as reducing breaches go, you'll get more bang for your buck by ensuring employees are up to date on their routine security awareness training. Your employees are much much easier to hack than your computers. "Choice of language" is a blip in the stats.
  - adrianN 2y ago
    > because some did not install updates of some component on the webserver But how many of those updates fix memory issues?
    - galangalalgol 2y ago
      I guess his point is that these bugs get found and patches are available before most people have to worry about it, because people don't burn zero day exploits unless it is very likely to net them more than the price of a zero day. But the people who handle enough value that they are worth a zero day still often use the same kernel, so they have an interest in paying to secure it. And separately, the people willing to burn a zero day are likely to be more careful in maintaining their access undetected, sometimes inserting evidence ahead of an investigation to indicate a different compromise route to preserve their zero day and potentially their access. And even if we are finding all these UB vulnerabilities before they get used, that is a giant cost we don't have to pay in new projects of we start them with something like rust. The infamous learning curve isn't a thing of you are coming from modern c++. I have never come across someone coming from c++ that didn't take to it immediately. Modern c might be a different story but I doubt it. Rewriting things should be reserved for codebases that are small, high risk, producing lots of vulnerabilities, or some combination of those. Unless someone just wants to do it for fun.
IshKebab 2y ago
> I think the sudden and almost exclusive focus on memory safety is weird. They're clearly panicking about people switching to Rust. I don't think it's surprising. Too little too late though; you can't just ignore people's concerns for decades and then as soon as a viable competitor comes along say "oh wait, actually we will listen to you, come baaack!". > There are lot of things compromising my online safety and freedom, and certainly memory safety issues are not very high on this list. Out of the things that programming languages can solve, memory safety should be very high on your list. This has been proven repeatedly.
- uecker 2y ago
  I don't see people panicking in my vicinity. I see some parts of the industry pouring money into Rust and pushing for memory safety. I agree that memory safety is nice, but some of the most reliable and safe software I use on daily basis is written in C. I am personally much more scared of supply chain issues introduced by Rust, or other issues introduced by increased complexity (which I still think is the main root cause of security issues).
  - galangalalgol 2y ago
    If you only need what is in the c std library the number of rust crates you use will be tiny and all from authors within the foundation. The hash gets stored in your repo, so any rebuilds where a dependency repo got compromised and tried to modify an existing version will fail. If you are using a c library that isn't std, then you will probably pull in 10x to 20x the number of dependencies in rust, but not substantially more authors. The risk is real, but if you treat it like c and minimize your dependencies it isn't any riskier, probably less. If you get tempted and grab everything and the kitchen sink you can still be reasonably safe by using the oldest version of crates you can compile with that don't have any cve. That is made easier with crates like cargo deny and cargo audit. All that said, I would love a language that had the same guarantees and performance without the complexity, but I don't see how that could work. There is definitely extra stuff in rust but the core capabilities come from the type system. Getting the same safety any other way would probably require a purely functional language which has performance costs in any implementation I am aware of along with a runtime being necessary. If you can afford that, then we don't need a new c, we have those languages.
ultimaweapon 2y ago
Most C/C++ users don't understand how Rust achieve memory safety because they don't know Rust enough. They always underestimate Rust memory safety. The truth is Rust can give you nearly 100% memory safety. The point of unsafe code in Rust is to isolate unsafe operations and provide a safe interface to it. As long as you wrote that unsafe code correctly the rest of your safe code will never have memory safety problems.
- bluGill 2y ago
  I've seen Rust code where everything was in unsafe because they thought it was needed (in 1% is probably was).
  - unboundedjiure 2y ago
    I've also seen Java code that recursively calls 1 row from database at a time, a million times per request with 5ms latency per row. It's possible to willingly abuse almost any system that a reasonable person would deem perfectly performant or safe for the purpose under default conditions. The question should less be about whether it's possible to try to abuse the system and more what it looks like in a very reasonable everyday scenario.
- pjmlp 2y ago
  They also conflate unsafe keyword with Rust, when its use in systems programming languages predates C by a decade. Here is the most recent version of NEWP manual, https://public.support.unisys.com/framework/publicterms.aspx?returnurl=%2faseries%2fdocs%2fClearPath-MCP-21.0%2f86002003-409.pdf https://public.support.unisys.com/framework/publicterms.aspx... Which started as ESPOL in early 1960's, https://en.wikipedia.org/wiki/Executive_Systems_Problem_Oriented_Language https://en.wikipedia.org/wiki/Executive_Systems_Problem_Orie... Binaries with unsafe code blocks are tainted, and must be white listed by admins to allow execution in first place. This was then followed by several languages, using unsafe code blocks, pseudo packages like SYSTEM, unsafe, unchecked,..., until finally Rust came to be. But since most C and C++ users aren't language nerds, not even reading their own ISO specification, they are unaware of the whole safety history since JOVIAL, and naturally the whole unsafe code blocks is all about Rust.

by uecker 2y ago

Sharlin 2y ago

I’m not sure how you can even try to juxtapose technical issues like memory safety with sociopolitical problems like corpo interests being in conflict with the interests of the common people. The formeer can be alleviated with technical solutions. There’s nothing that a programming language can do about the latter. Also, I question your claim that memory unsafety is not of great importance to regular computer users. Perhaps not if your computer is airgapped from the internet and never gets any unvetted software installed. Otherwise, have you missed the primary cause of the majority of CVEs issued in the past decades? Do you not think that the main technical problem behind countless security vulnerabilities, that have very concretely affected tens and hundreds of millions of people, does not deserve the attention that it’s finally starting to get? Google has reported that the mere act of stopping writing new code in memory-unsafe languages has made the fraction of mem safety vulnerabilities drop from >80% to ~20% in a few years. This is because bugs have a half-life, and once you stop introducing new bugs, the total count starts going down asymptotically as existing bugs get fixed. Finally, since you inevitably mentioned Rust, memory safety is indeed a necessary but not sufficient condition in software reliability. Luckily, Rust also happens to greatly decrease the odds of logic bugs getting in, thanks to its modern (i.e. features first introduced in ML in the 70s) type system that actually tries to help you get things right. C is never going to have those parts, the “if it compiles, it is correct by construction” assurance. C++ has janky, half-assed, non-orthogonal, poorly-composing, inconsistently designed versions of a lot of the stuff, but it also has all of the cruft, and that cruft is still what is taught to people before the less-bad parts. And because C++ is larger than the most people’s brain capacity, most people can’t even get to the more less-bad parts, never mind keeping up with new standard versions.

uecker 2y ago
Technology and society are never separate things. The question if why something is seen as important or not, and what is funded, very much depends on societal questions. I am using Linux for almost 30 years. I have never been hacked, or know anybody personally, who was hacked because of a memory safety issue in any open-source component. I know such people and companies exist, I just know many more which are affected by other issues. I know many people affected by bugs in Microsoft software, including myself. I am also affected by websites spying on me, from email not being encrypted by default, etc. A lot of things could be done do make my safety and security better. That you cite Google actually demonstrates the problem: Memory safety is much more their concern, not mine. And C definitely will have memory safety. Stay tuned. (And I also like to have memory safety.) I do not care about C++ nor do I care about Rust. Both languages are far too complex for my taste.
bluGill 2y ago
> Otherwise, have you missed the primary cause of the majority of CVEs issued in the past decades Only because CVEs are never issued when humans are compromised. While that is probably the correct action on their part it means your argument is flawed as you don't account for human vulnerabilities which are much more common. Yes memory safety is a big problem and we should do something - but as an industry we need to not ignore the largest problem. There is a lot we can do in UX to prevent most security vulnerabilities, and putting too much emphasis on memory can take away from potentially more productive paths.

galangalalgol 2y ago

Can you clarify why memory safety isn't your main problem? Do you just mean that UB isn't your biggest problem, or that memory safety isn't your biggest source of UB? The latter sounds unlikely, and the former is interesting as all the code I give away for free gets used by people who very much care if it has UB.

uecker 2y ago
When we talk to companies that are in the business of helping other companies that were hacked, the stories we hear are never that they were hacked by some 0-day in the Linux kernel or a server software caused by some memory-safety issue. Instead, they are hacked because some did not install updates of some component on the webserver, password authentication was used, the same passwords are used on different servers, etc. or some bug in some overly complex Microsoft infrastructure part.
- lelanthran 2y ago
  > Instead, they are hacked because some did not install updates of some component on the webserver, password authentication was used, the same passwords are used on different servers, etc. or some bug in some overly complex Microsoft infrastructure part. Last I checked (a few months ago) 8 out of 10 breaches were due to human error. As far as reducing breaches go, you'll get more bang for your buck by ensuring employees are up to date on their routine security awareness training. Your employees are much much easier to hack than your computers. "Choice of language" is a blip in the stats.
- adrianN 2y ago
  > because some did not install updates of some component on the webserver But how many of those updates fix memory issues?
  - galangalalgol 2y ago
    I guess his point is that these bugs get found and patches are available before most people have to worry about it, because people don't burn zero day exploits unless it is very likely to net them more than the price of a zero day. But the people who handle enough value that they are worth a zero day still often use the same kernel, so they have an interest in paying to secure it. And separately, the people willing to burn a zero day are likely to be more careful in maintaining their access undetected, sometimes inserting evidence ahead of an investigation to indicate a different compromise route to preserve their zero day and potentially their access. And even if we are finding all these UB vulnerabilities before they get used, that is a giant cost we don't have to pay in new projects of we start them with something like rust. The infamous learning curve isn't a thing of you are coming from modern c++. I have never come across someone coming from c++ that didn't take to it immediately. Modern c might be a different story but I doubt it. Rewriting things should be reserved for codebases that are small, high risk, producing lots of vulnerabilities, or some combination of those. Unless someone just wants to do it for fun.

IshKebab 2y ago

> I think the sudden and almost exclusive focus on memory safety is weird. They're clearly panicking about people switching to Rust. I don't think it's surprising. Too little too late though; you can't just ignore people's concerns for decades and then as soon as a viable competitor comes along say "oh wait, actually we will listen to you, come baaack!". > There are lot of things compromising my online safety and freedom, and certainly memory safety issues are not very high on this list. Out of the things that programming languages can solve, memory safety should be very high on your list. This has been proven repeatedly.

uecker 2y ago
I don't see people panicking in my vicinity. I see some parts of the industry pouring money into Rust and pushing for memory safety. I agree that memory safety is nice, but some of the most reliable and safe software I use on daily basis is written in C. I am personally much more scared of supply chain issues introduced by Rust, or other issues introduced by increased complexity (which I still think is the main root cause of security issues).
- galangalalgol 2y ago
  If you only need what is in the c std library the number of rust crates you use will be tiny and all from authors within the foundation. The hash gets stored in your repo, so any rebuilds where a dependency repo got compromised and tried to modify an existing version will fail. If you are using a c library that isn't std, then you will probably pull in 10x to 20x the number of dependencies in rust, but not substantially more authors. The risk is real, but if you treat it like c and minimize your dependencies it isn't any riskier, probably less. If you get tempted and grab everything and the kitchen sink you can still be reasonably safe by using the oldest version of crates you can compile with that don't have any cve. That is made easier with crates like cargo deny and cargo audit. All that said, I would love a language that had the same guarantees and performance without the complexity, but I don't see how that could work. There is definitely extra stuff in rust but the core capabilities come from the type system. Getting the same safety any other way would probably require a purely functional language which has performance costs in any implementation I am aware of along with a runtime being necessary. If you can afford that, then we don't need a new c, we have those languages.

ultimaweapon 2y ago

Most C/C++ users don't understand how Rust achieve memory safety because they don't know Rust enough. They always underestimate Rust memory safety. The truth is Rust can give you nearly 100% memory safety. The point of unsafe code in Rust is to isolate unsafe operations and provide a safe interface to it. As long as you wrote that unsafe code correctly the rest of your safe code will never have memory safety problems.

bluGill 2y ago
I've seen Rust code where everything was in unsafe because they thought it was needed (in 1% is probably was).
- unboundedjiure 2y ago
  I've also seen Java code that recursively calls 1 row from database at a time, a million times per request with 5ms latency per row. It's possible to willingly abuse almost any system that a reasonable person would deem perfectly performant or safe for the purpose under default conditions. The question should less be about whether it's possible to try to abuse the system and more what it looks like in a very reasonable everyday scenario.
pjmlp 2y ago
They also conflate unsafe keyword with Rust, when its use in systems programming languages predates C by a decade. Here is the most recent version of NEWP manual, https://public.support.unisys.com/framework/publicterms.aspx?returnurl=%2faseries%2fdocs%2fClearPath-MCP-21.0%2f86002003-409.pdf https://public.support.unisys.com/framework/publicterms.aspx... Which started as ESPOL in early 1960's, https://en.wikipedia.org/wiki/Executive_Systems_Problem_Oriented_Language https://en.wikipedia.org/wiki/Executive_Systems_Problem_Orie... Binaries with unsafe code blocks are tainted, and must be white listed by admins to allow execution in first place. This was then followed by several languages, using unsafe code blocks, pseudo packages like SYSTEM, unsafe, unchecked,..., until finally Rust came to be. But since most C and C++ users aren't language nerds, not even reading their own ISO specification, they are unaware of the whole safety history since JOVIAL, and naturally the whole unsafe code blocks is all about Rust.