6 ms·

> any safety checks put into the competing language will have a runtime cost, which often is unacceptable. And what is the runtime cost of all the mitigations

• lisper 4y ago
  And who says that faster runtime trumps all other considerations? I would much rather have my computer run slower than have to continuously deal with security vulnerabilities. My time is much more valuable than CPU time.
  • elcomet 4y ago
    That's not the point. The point the parent is making is that yes, languages that include safety features are slower, but you will actually need those safety features in C as well, in the code. So your program will also be slower in C.
    • lisper 4y ago
      Yes, I think we're actually all in agreement here. The common point is that TFA's argument that we need to keep C because it's faster is invalid. The GP's point is that it is not in fact faster because of all the things you need to do to produce code that can actually be deployed in today's world. My point is that even if C were faster (which it actually isn't) that would not matter because C is unsafe even with all the extra stuff that people stick onto it to try to make it safe. So the original claim is really a judgement call that speed matters more than safety, and this is not something about which there is any kind of consensus.
    • sitkack 4y ago
      What does slower actually mean? Slower in the face of safety, while computers continue to get faster and or cheaper (depending on how you spend your transistors/cost) is a fools paradise. Don't be baited into their flawed logic. If your transistor/cost curve has a doubling time of 3 years, 156 weeks. A 5% difference is approximately 11 weeks. If your transistor/cost curve has a doubling time of 2 years, a 5% difference is approximately 8 weeks. How fast do we have to get before safety is table stakes? Focusing on raw unsafe speed wouldn't be a normalized metric in any other industry. I'll spend 8-11 weeks of performance gains on correctness. C was an inside job.
    • Gibbon1 4y ago
      There is something backwards about how safety checks are done in C. First it's up to the programmer to put them in. Then hopefully the compiler will optimize away the unneeded ones. If the programmer though biffs and forgets then oops. And of course classically we blame the programmer not the system he's been forced to work under. That seems like a reasonable thing in 1982. Which is 40 years ago. It would be better if the compiler implemented the checks automagically and removed ones it knows it doesn't need. And bonus, if the programmer puts one in, leave it alone.
  • ryandrake 4y ago
    > I would much rather have my computer run slower than have to continuously deal with security vulnerabilities. My time is much more valuable than CPU time. To be devil’s advocate and take the other side of this argument: I would rather the CPU I paid for spend its cycles performing actual application logic. Every cycle spent executing all this “safety code” overhead feels like me having to pay for a developer’s sloppiness. I feel end users pay a high cost for all this runtime checking and all these frameworks and levels of abstraction.
    • quickthrower2 4y ago
      Is Rust slower then C in general though? And how much are you paying? Probably in true terms it costs less if there are fewer bugs and vulns.
    • lisper 4y ago
      First, not all language safety features have to manifest themselves as run-time checks. A properly designed language will allow many safety checks to be done at compile-time. And second, would you really rather deal with security holes on an on-going basis? The problem with C is not that you can write unsafe code in it, it is that the design of the language -- and pointer aliasing in particular -- makes it impossible to perform even basic sanity checks at compile time [EDIT: or even at run-time for that matter]. For example: int x[10]; ... int y = x[11]; In any sane language, that would be a trivially-checkable compile-time error. But in C it is not because there are all kinds of things that could legally happen where the ellipses are that would make this code not violate any of C's safety constraints. That is the problem with C, and it is a fundamental problem with C's design, that it conflates pointers and arrays. C was designed for a totally different world, and it is broken beyond repair.
      • jsnell 4y ago
        Bad example. There's nothing[0] you could put in the ellipsis to make that code valid, and both gcc and clang will warn about it (clang on defaults, gcc with -Wall). [0] Ok, I guess you could #define x something, but that's not interesting from a static analysis perspective.
  • TylerE 4y ago
    You're assuming that safety features will prevent security bugs. I think that is...optimistic at best. Yes, they can defeat a few classes of exploits, but generally not the ones that lead to really bad outcomes.
    • mcpherrinm 4y ago
      > The Chromium project finds that around 70% of our serious security bugs are memory safety problems. > ~70% of the vulnerabilities Microsoft assigns a CVE each year continue to be memory safety issues Memory safety is a leading source of serious bugs in a big group of operating systems, browsers, image and file parsers, and more. It does seem likely we can stop this, and it doesn’t seem likely to me we can fix it in C. We have tried and failed for years at that.
      • pjmlp 4y ago
        Solaris SPARC is the first that has suceeded at it, and now others follow it, how? Hardware memory tagging, the language itself is beyond hope.
    • lisper 4y ago
      I can't respond to that unless you are more specific about what are "the ones that lead to really bad outcomes". There are a lot of arbitrary-code-execution attacks that are enabled by buffer overflows, and IMHO that's as bad as it gets. There is absolutely no legitimate excuse for a buffer overflow in today's world. Switching to safe(r) language won't prevent all attacks, but it will make a big dent.
    • sitkack 4y ago
      If you remove the mechanically preventable bugs from being a consideration, by definition the only one you now need to focus on are the ones NOT prevented by mechanism. How is this not a win? We only have so many decisions we can make per day.
      • tempest_ 4y ago
        A lot of people make perfect the enemy of good.
• bee_rider 4y ago
  You are the security engineer, so you certainly know better than me, but aren't those runtime mitigations aimed at malicious programs? Which is to say, even if a better-C was written that didn't allow people to write a program that would bump into those mitigations, the bad guys could still write their programs in assembly or C or whatever, right?
  • AgentME 4y ago
    Sandboxing techniques can also be used for dealing with malicious programs, but most of those things listed are for programs to use to protect themselves, not to stop them from intentionally doing bad things.
  • woodruffw 4y ago
    They're aimed at protecting innocent programs from exploitation. If we knew which programs were actually malicious, our lives would be much easier!
    • bee_rider 4y ago
      But the presence of a better language to write innocent programs in wouldn't protect the innocent programs from malicious programs written in C and assembly...
      • atwood22 4y ago
        Yes, a better language would protect innocent programs. Take stack canaries. They are to protect stack corruption due to an application bug, e.g. unsafe input handling. Input handling is perfectly safe in many other languages, but C has a lot of footguns.
      • woodruffw 4y ago
        I don't understand this response. Nothing really stops that, regardless of implementation language. It's why we have an entire bodged and mostly ineffective AV industry, as well as a slightly less bodged and partially effective endpoint monitoring/detection industry. Runtime mitigations exist to mitigate some of the latent risk associated with programming in unsafe programming languages. We use them because they're our best known approach to continuing to use those languages without letting script kiddies own us like it's 1993.
• dist1ll 4y ago
  This is why I hope unikernels & Rust will eventually replace docker & linux for high-performance, high-security production deployments.
  • pkrumins 4y ago
    Rust will not replace anything because it’s impossible to write code in it. Everything you write is a syntax error that requires an exobrain to figure out.
    • woodruffw 4y ago
      What's the point of this hyperbole? We have ample evidence that thousands of engineers (and large companies) are successfully applying Rust.
      • Jtsummers 4y ago
        GP has been posting the same thing in many threads when Rust comes up. Apparently they think it's funny, or they're really bad at writing Rust code and feel like venting.
    • dawnbreez 4y ago
      ...in a lot of the cases I ran into early on, the rust compiler literally told me what to change.
  • elihu 4y ago
    I agree. I think of address space context switching overhead as the performance price we pay for not being able to run all our programs in a single address space, which we could safely do if we knew all the programs were emitted by a trusted compiler that disallows unsafe memory access. Imagine if system calls were just ordinary functions that can be called with no more than the normal function call overhead? What if they could even be inlined? Obviously there's a lot of little details you'd have to work out. Like how to make such a trusted compiler in the first place, and how to sandbox unsafe code and legacy applications that were compiled by an untrusted compiler. If this seems like it's far-fetched or too much work, consider what lengths high-performance hardware devices like HPC network interfaces go to avoid system calls at all costs, to the point where applications talk to the hardware directly. Is that really a sustainable practice long term? And how can anyone audit the security of such hardware devices?
• pjmlp 4y ago
  And the latest trend, producing C Machines with hardware memory tagging, because none of those mitigations are actually working preventing all those CVE to take place.