back to article NSA urges orgs to use memory-safe programming languages

The NSA has released guidance encouraging organizations to shift programming languages from the likes of C and C++ to memory-safe alternatives – namely C#, Rust, Go, Java, Ruby or Swift. "NSA recommends that organizations use memory safe languages when possible and bolster protection through code-hardening defenses such as …

  1. Anonymous Coward
    Anonymous Coward

    The more things change

    Perhaps I'm old and cynical, but I can't help but feel that: "it'll take decades before we clean up this mess" should really be: "it'll take decades before we replace this mess with a different mess"...

    1. fg_swe Bronze badge

      Re: The more things change

      I take it you use a horse carriage instead of these newfangled explosion-engine carriages ? Too dangerous !

      1. Tom 7

        Re: The more things change

        A new fangled explosion carriage with several thousand new levers in different positions to learn over the single bridle and a couple of stirrups? While waiting for the roads to be widened so you can get to the new libraries that will probably never be re-written,

        1. fg_swe Bronze badge

          Re: The more things change

          So you are posting from Kandahar ?

          I suggest an explosion engine bicycle from Yamaha. Your warriors use them to great effect.

    2. I miss PL/1

      Re: The more things change

      No language was ever developed with safety as a primary goal.

      It's like the argument that we can make completely safe cars but then they would be so expensive they would be impractical to drive.

      1. fg_swe Bronze badge

        FALSE

        Rust, Swift, SAPPEUR, SPARK ADA were specifically designed to realize advanced safety mechanisms. Ranging from a special type system to the assertion system of SPARK, which is even more powerful.

        1. swm

          Re: FALSE

          Common Lisp is a safe language but you can still create programs that don't work properly.

          1. Michael Wojcik Silver badge

            Re: FALSE

            Of course you can. Safer programming languages aren't intended or imagined to enforce correct programs. They exist to reduce the attack surface, and free resources such as programmer attention for harder problems, such as correctly implementing the desired functionality.

      2. t245t
        Mushroom

        Re: The more things change

        @I miss PL/1: “No language was ever developed with safety as a primary goal

        Yea, if it compiles ship it out the door. We'll fix the bugs in the next version with bug reports from the long suffering end-users /s

  2. AMBxx Silver badge
    Windows

    Better compilers?

    I am but a humble SQL consultant who 'does a bit' in C# & Java (history of all sorts going back to Fortran, Pascal etc).

    Is there any reason why memory safe can't be enforced in the C/C++ compilers?

    1. sitta_europea Silver badge

      Re: Better compilers?

      "...Is there any reason why memory safe can't be enforced in the C/C++ compilers?"

      It doesn't have to be in the compilers.

      I did it more than 30 years ago in C libraries for an accounts package that I wrote. For example I replaced malloc() with my own version, which did a bit more (and so admittedly sacrificed some performance) but made the use of memory allocation for the rest of the package entirely safe and guarded against any and all overflows. IMO it was the only way to tame what was otherwise an obvious footgun.

      The package is still running, still sending invoices, now even making VAT returns. Never a crash that wasn't caused by the hardware or the underlying OS. When someone called one of the users about a credit note and said that there must be a bug in it, the user laughed out loud.

      And what's all this about Java and JavaScript? Weren't some of the biggest recent disasters written in those languages (log4j, npm)?

      You can demonstrate incompetence in ANY computer language.

      1. Anonymous Coward
        Anonymous Coward

        Re: Better compilers?

        >Weren't some of the biggest recent disasters written in those languages (log4j, npm)?

        Yes, but in both cases those disasters could be fixed in config. Something like 70% of severe vulnerabilities stem back to memory safety, which are much more challenging to detect, more challenging to fix and much more challenging to limit the blast radius.

      2. fg_swe Bronze badge

        JavaScript: Weak Typing

        JavaScript is in some ways memory-safe, but certainly not in the spirit of Rust or Sappeur. For example, JS records don't have a type. Each instance of record can contain other members. Or same named members with different types.

        Rust, Sappeur, Spark Ada - they are Strongly Typed

        1. Anonymous Coward
          Anonymous Coward

          Re: JavaScript: Weak Typing

          Any article about C, C++, or memory safety and you're spamming the forum and derailing every thread to flog your version of TypeScript. Why don't you pay for advertising like everyone else?

          1. fg_swe Bronze badge

            Re: JavaScript: Weak Typing

            I have been the re-initiator* of the Memory Safe System Programming Idea at around 2009. Rust and Swift have been created after I showed Sappeur to Mozilla and Apple.

            Now NSA agrees with me and I am happy. If you don not share my happiness, just go to a different discussion. Thanks.

            *Standing on the shoulders of Hoare, Bauer, ICL, Burroughs, MIPM

            1. Anonymous Coward
              Anonymous Coward

              Re: JavaScript: Weak Typing

              Rust is well-documented to have originated in 2006.

              1. ssokolow

                Re: JavaScript: Weak Typing

                ...and its ancestry is clearly documented as tracing through languages like Cyclone and Ocaml, the former of which developed from 2002 to 2006 and Rust's ownership-and-borrowing paradigm is an evolutionary improvement on.

      3. Tom 7

        Re: Better compilers?

        30 years ago I was writing grep and other apps that prevented me even trying to compile C code with any possible memory leak and fuckup code I could identify. Some of this in GCC warning etc and I get the impression LLVM was designed with this is mind but seems people would rather redesign the wheel than ping a few spokes.

        1. fg_swe Bronze badge
          FAIL

          Elaborate

          Which mythical-magical C compiler did this "30 years ago". What you describe cannot be done with LLVM or GCC TODAY.

          I call Male Cow Excrement.

          1. sten2012 Bronze badge

            Re: Elaborate

            Keyphrase seems to be "that I could identify".

            Also "memory leaks" rather than "memory corruption".

            If we could identify them all then we wouldn't have this issue and need memory safe languages, but alas, we do.

            No necessarily for every context but they should be the default and deviating from that default justified.

            Use of unsafe languages should be a code smell by default, not necessarily forbidden, but called out for the risk it is.

      4. mmstick

        Re: Better compilers?

        There's far more to memory safety than a custom malloc implementation could ever resolve. This does very little to achieve anything resembling memory safety. It does not achieve aliasing XOR mutability, any form of thread safety, or even to ensure the correct usage of pointers and data which ownership and move semantics resolves. No amount of code written or used in production with C can invalidate that or the large body of work that proving it to be necessary.

        For starters, search for "Region-based memory management in Cyclone, by D Grossman 2002". This results of this research are a primitive form of the lifetime annotation syntax that you see in Rust today. One of many features that combined make memory safety possible.

    2. Anonymous Coward
      Anonymous Coward

      Re: Better compilers?

      >Is there any reason why memory safe can't be enforced in the C/C++ compilers?

      Yes. This has been tried before.

      The challenges are twofold. First is that you can only go so far with compiler-side checks. True memory safety is really a combination of (at least) thread safety, null safety and type safety in addition to the raw bounds checking most people are thinking of. Unless you're going to head off into managed language land and bring in a GC, you need language-level constructs to allow the programmer to work within these new bounds effectively. In Rust this is the "ownership" system, for example.

      The second is that you almost always end up restricting the language features to some limited, safer set or replacing core functionality (e.g. malloc or the compiler) with something custom. This restricts the libraries you can use to those using your feature set, and requires you to maintain that core functionality ad infinitum. And even then you won't get "true" safety because it depends on everyone being careful and not using the wrong combination of features or compiler or versions and you being super sure your core implementation is itself safe. You can see a good example of this in D's "Better C", which is a true C compiler with memory safety, but without classes or exceptions. Or there's an older project called Cyclone which ends up effectively prohibiting pointer arithmetic.

      So if you go all in on this, you're at the point where you need a specific compiler, plus a different set of core language features, plus you need to make sure all your supporting libraries are compliant, plus now you probably need bespoke supporting tooling for your static analysis and compile toolchain; so you may as well make life easier with some new syntax and higher-level features... you've basically developed Rust.

      1. Michael Wojcik Silver badge

        Re: Better compilers?

        The second is that you almost always end up restricting the language features to some limited, safer set or replacing core functionality (e.g. malloc or the compiler) with something custom.

        This is an important point. You can't have completely memory-safe C at the translation ("compiler", though C does not, strictly speaking have to be compiled) level, because you'd have to violate the C standard in various ways. For example, the translator can't tell how large an object with dynamic lifetime might be, nor how large an object passed by an external caller might be.

        If it's a hosted C implementation, as most are, you have to provide malloc and friends. That's required by the standard unless it's a freestanding implementation.

        So you might create a language which is similar to C with additional memory safety, but you're stuck with an uneasy compromise: something that isn't C enough to correctly translate and execute all conforming C code, but doesn't achieve the degree of memory safety you can get in something like Rust.

        D is probably as good an attempt at a safer C as anyone's going to produce. C++, used in a careful, Stroustroppian manner, can achieve a decent level of safety; but C++ is also, as a language, required to carry a great deal of baggage. It's also huge (the C standard is large but comprehensible; the C++ standard defies the understanding of mortals), which makes it hard to reason about in general, and the vast majority of the considerable quantity of C++ code I've seen is rubbish, which suggests that many C++ developers find it difficult to be vigilant about their use of it.

        No programming language is perfect. I like LISP and Scheme; I like OCaml and F#; I like Rust. I'm not particularly fond of Go, but I don't think it's objectively bad. I've enjoyed writing OO COBOL for .NET (which is not very COBOLy, to be honest), of all things. I've done a couple of non-trivial things in Java, and I don't mind working with it once I get back in the habit. I wrote a couple of academic projects in Javascript (for Reasons) and that was fun, though I wouldn't want to do anything big in the language, and third-party Javascript libraries are a plague. But all these have their faults, too.

        Most of my work is still in C, and will continue to be for the foreseeable future.

    3. Sceptic Tank Silver badge

      Re: Better compilers?

      I can't believe I'm reading this! Are you suggesting that a C programmer sacrifice speed for safety? Such a thing is just not done.

      I think C++ went a very long way to address the memory safety issues but it still offers rubbish programmers the facilities to write dangerous code if they so wish.

      1. fg_swe Bronze badge

        Wrong

        C++ does offer some mechanisms towards memory safety, such as smart pointers, operator[] overloading and RAII. BUT - all of this depends on software engineer self-discipline. AND - there is no multithreading race condition safety assurance in C++, whatsoever.

        All of this can be achieved by a proper type system, runtime check code and (multithtreaded if needed) ARC.

        http://sappeur.ddnss.de/

        1. Tom 7

          Re: Wrong

          or Boost.

          1. fg_swe Bronze badge

            Re: Wrong

            Boost cannot enforce type safety and especially does nothing to ensure MT memory safety.

            1. DrXym

              Re: Wrong

              I've used boost for years and it's a really useful addition but neither boost nor the compiler will care if you remember to lock access to shared data. The usual way is to create a mutex and lock it from the block where the data is accessed, but nothing will complain if you don't.

              By contrast in Rust you *can't* share data between threads unless you either send it to the other thread, or use reference counting and a mutex / rwlock. You can't even access the data without acquiring the lock first.

              1. fg_swe Bronze badge

                BINGO

                "but neither boost nor the compiler will care if you remember to lock access to shared data."

                You describe a race condition which will likely damage heap integrity and secondly have uncontrollable follow-on effects.

                In other words, MT safety is a key feature of Memory Safety. SAPPEUR solves this by reflecting thread-shared memory in the type system and automatially generating Mutex lock code. Also, the ARC will be MT safe in this case(which is more expensive than ST ARC).

                ARC: automatic reference count

                MT: multithreaded

                ST: singlethreaded

        2. Rich 2 Silver badge

          Re: Wrong

          “… no multithreading race condition safety assurance in C++, whatsoever.”

          Not true. At all. Not in the least little bit

          1. fg_swe Bronze badge

            Elaborate

            how ?

            1. Rich 2 Silver badge

              Re: Elaborate

              There’s a whole lump of the standard library dedicated to providing all the stuff you need to handle multithreaded code and the synchronisation mechanisms that operate between them

              1. fg_swe Bronze badge

                Misunderstanding

                Sappeur ENFORCES that multithreaded data structures are protected by Mutexes. In C++ you can easily create a thread-shared variable and forget the mutex to protect this variable. Nasty heap errors will likely result.

                1. Richard 12 Silver badge

                  Re: Misunderstanding

                  Mutexes doesn't mean thread safe, and not using a mutex doesn't make it unsafe. There are a lot of lock-free multiprocessing schemes.

                  Just tossing mutexes about is often slower than need be, and can even result in livelocks and deadlocks unless you actually do know what you're doing.

                  It's rather common to pass a huge array of "stuff to do" to a big pile of worker threads, then do something else (eg spin a waiting indicator) until all those threads finish (joined or whatever the language calls it).

                  A language-enforced mutex would make that slow or extremely slow, depending on where it decided to out the lock.

                  1. fg_swe Bronze badge

                    Re: Misunderstanding

                    simply using

                    static std::string sharedString;

                    and then write-accessing sharedString from two threads will prolly destroy your heap integrity. In Sappeur this will either not compile, or the sharedString will be a "multithreaded" object and protected a mutex. And yes, you still need to use your brain and know what to do to achieve good performance.

                2. Rich 2 Silver badge

                  Re: Misunderstanding

                  “ In C++ you can easily create a thread-shared variable and forget the mutex to protect this variable”

                  And you can easily construct something that enforces the use of the mutex to access the variable. It’s trivial to do

                  1. fg_swe Bronze badge

                    Explain

                    How can it be done "easily" using C++ in such a way that:

                    1.) Single-Threaded objects/data does not need mutexes and MT-safe ARC.

                    2.) Multithreaded objects/data is guaranteed to be mutex-protected or MT-safe.

                    I bet you cannot with the current C++ standard.

      2. DrXym

        Re: Better compilers?

        C++ went some way to help with safety. Smart pointers for example. But it's still incredibly easy to screw up in C++ and the compiler won't care. It's all very well to blame "rubbish programmers" but the world is filled with mediocre and crap programmers and the programming language isn't doing all it could to beat some sense into the code they write. This is why *everyone* is looking at safer alternatives these days. Rust would be a prime example but NVidia has SPARK, Google has Carbon plus there are other modern programming languages that will unwind in a graceful way rather than crash or be exploited by C++.

        1. fg_swe Bronze badge

          Immediate Crash vs. Subversion

          An immediate crash*, which can be debugged, is much better than "soldiering on with virus injected". The latter you can get with non memory safe programs.

          * from out of bounds access or from a NULL pointer reference.

    4. StrangerHereMyself Silver badge

      Re: Better compilers?

      Because C (from which C++ is derived) is a Systems Programming Language, used to write operating system and low-level code in. You specifically don't want any run-time checking or behind the curtain behavior there.

      I always say: C is high-level assembly language and as such you need to handle it with care. Using it as a Application Programming Language is foolish.

      1. Anonymous Coward
        Anonymous Coward

        Re: Better compilers?

        This isn't really correct. You don't need "run time checking" or "behind the curtain behaviour" to achieve memory safety. Rust does this with explicit memory ownership. The presence of these things does not preclude use as a systems language. OCaml is an example of a successful systems-oriented language that includes a bunch of "behind the curtain behaviour".

        1. fg_swe Bronze badge

          Re: Better compilers?

          OCaml is a LISP variant, correct ?

          So it can never achieve the efficiency and realtime capabiities of an imperative language ?

          1. Michael Wojcik Silver badge

            Re: Better compilers?

            OCaml is a LISP variant, correct ?

            No. OCaml is a member of the ML family, which also includes Standard ML and Haskell. The ML and LISP families are not closely related. Five seconds of research would have told you that.

            So it can never achieve the efficiency and realtime capabiities of an imperative language ?

            This is precisely the sort of handwaving bullshit that lets your readers know you have no real arguments to offer, and they can safely ignore you.

            1. fg_swe Bronze badge

              OCaml

              So OCaml is not LISP, but shares all the hallmarks of LISP: functional programming, immutable state, garbage collection. All of that translates into inefficiency and a lack of realtime capabilities.

              For some problems, functional programming is definitely the right solution, but not for others such as realtime control, realtime signals processing, realtime GUIs and the like. Also, GC typically requires 2x the memory of an ARC-based equivalent program.

              1. fg_swe Bronze badge

                Ocaml II

                According to

                https://ocaml.org/docs/first-hour

                it is a two-headed beast which can also do imperative programming with mutable state ("variables"). So it is a kind of LISP married with Algol...

      2. Jason Bloomberg Silver badge
        Coat

        Re: Better compilers?

        I always say: C is high-level assembly language and as such you need to handle it with care. Using it as a Application Programming Language is foolish.

        That's been my view as well. Being unsafe is baked into the language. It was and is appropriate for what it was intended for but not in applications where no end of effort has been - and has to be - expended trying to mitigate its unsafe nature.

        I can understand why people ended up using C for everything but it was foreseeably walking a path to the inevitable nightmare. "Don't use C for applications" has been said for decades but mostly ignored.

        Mine's the one next to the growling lion holding a flick knife and a bottle of Novichok. No; it's perfectly safe if you approach it right.

      3. Dirk Munk

        Re: Better compilers?

        Actually, C and Unix were made for educational purposes, and were never meant for production. The same applies to Pascal.

        C is indeed meant as an assembler replacement, and you're very right with your remark that you should never use it as an Application Programming Language. Tell that to C programmers. High level languages will add checks in the code, C will not. Checks like you defined a variable as numeric, is the data you want to move to the variable indeed numeric? Or, you defined a table with 100 entries, is the value in the pointer in range, so that you can't read or write "entry" 200 ? Yes, it will make the application slower, but so what. I want reliable code.

        I remember a programmer complaining about C on VMS. The C compiler was always complaining about errors in the source, Unix didn't have that problem. I understand why ..........

        Ada was designed to produce error free applications. Someone once told me that if you wrote a 100 lines Ada source, you would most likely get 200 lines of errors after the first compilation.

        With all the computing power we have these days, it is time to start using languages that can produce error free code by adding code for checks that the programmer will not add, and should not be required to add.

    5. Paul Crawford Silver badge

      Re: Better compilers?

      Complete memory safety cannot be enforced in C/C++ in any practical manner.

      Good programming practice goes a long way, and there are guides for C programming for safety critical systems such as cars (see MISRA guidance), etc, available that go through the sub-set of syntax you should use and things to avoid doing as they commonly result in bugs.

      However, you (and others) can go a long, long way to avoiding problems by turning on the highest warnings and using various analysis tools, both static (e.g. lint, coverty scan, etc) and dynamic testing (e.g. the electric fence library, valgrind). I would be willing to be a large portion of security faults come from not listening to and correcting warning (possibly as legacy code had so much that developers wound back on the checks).

      Beyond that, and for all languages, you can also use tools such as AppArmor for mandatory access control so software once executing is limited in what it can do by rules designed around what it should do.

      Sadly try that with many programs like web browsers and its a complete mess of rules and requests for stuff you really, REALLY wonder wtf the developers thought they needed to poke around all sorts of places in the OS just to play cat videos and brows the web.

      1. fg_swe Bronze badge

        Well

        Strongly typed, memory safe languages do what you say, in a strict fashion. The static checkers you mention are incomplete and heuristically driven.

        AppArmor is a different approach; coarse-grained and treating the program as a black box. It makes sense to not mix up memory safety and sandboxing, for clarity of thinking.

        1. Version 1.0 Silver badge

          Re: Well

          These days Rust etc are seen as "safe" because the hackers find it easy to hack other languages, if we move ahead with the NSA plans then the hackers will start hacking Rust and all other "safe" languages.

          1. fg_swe Bronze badge

            Re: Well

            The hackers will have 70% less opportunities. See CVE database.

            1. DrXym

              Re: Well

              The CVE database is an excellent place to highlight the stupidity of people defending C (or C++). Look at the Linux kernel CVEs and the majority are for things like double free, call after free, buffer overflow, data race etc. I think we can all agree that the kernel devs are at the top of their game, probably knowing more about C than anyone else and yet the majority of their bugs are caused by the language it is written in.

              1. fg_swe Bronze badge

                Re: Well

                Thanks. That is what I am saying for years now.

          2. mmstick

            Re: Well

            If you think it's that easy to discover exploits for software written in Rust, then by all means, go forth and discover them and report your results.

      2. sitta_europea Silver badge

        Re: Better compilers?

        "...Sadly try that with many programs like web browsers and its a complete mess of rules and requests for stuff you really, REALLY wonder wtf the developers thought they needed to poke around all sorts of places in the OS just to play cat videos and brows the web."

        I wish I could upvote that ten more times.

        1. ssokolow

          Re: Better compilers?

          Which is why people are getting fed up and turning to the "just containerize the bleeping thing" route used by things like Flatpak and Snap.

          Sure, you still need to grant far too much access, but that's inherent when your browser is taking over from X.org for "OS running on top of the OS" status and the API surface for XDG Portals (the Linux equivalent to Android Intents) is still getting built out.

          (eg. It's got a file/directory chooser portal that Firefox will use, but support for "When I pick this .html file, also mount the adjacent _files directory into the sandbox" is an open bug.)

    6. ssokolow

      Re: Better compilers?

      Two main reasons:

      1. The C and C++ language syntaxes don't, by default, provide enough information to the compiler. Attempts have been made to extend them on various occasions, but they're ugly and people don't use them.

      2. They have huge ecosystems that don't use such annotations. When you switch languages, the act of annotating the APIs to be verifiable for correct use gets rolled into "writing bindings to the C or C++ code".

    7. Abominator

      Re: Better compilers?

      the ISO C++ 20 already has everything for memory safety for general purpose programming.

      But even Rust like C, C++, for low level allocator development has to be unsafe in that you operate on bytes, before framing them as objects.

      https://www.theregister.com/2022/09/28/is_it_time_to_retire_c/

      "And, as Bjarne Stroustrup, C++'s creator, told The Register recently: "We can now achieve guaranteed perfect type and memory safety in ISO C++."

      ""We can now achieve guaranteed perfect type and memory safety in ISO C++. That is, every object is used according to the type it was defined with. That implies that we eliminate uses of dangling pointers, catch range errors, and eliminate data races. Note that every 'safe' language, including Rust, has loopholes allowing unsafe code."

      It is quite easy to enforce.

      1. fg_swe Bronze badge

        Really ?

        How will the compiler force you to not use pointer arithmetics ?

        How will the compiler check for accidentally shared thread-global objects and stop compiling ?

        How will the compiler stop you from obtaining a pointer to a stack-allocated object and store the pointer somewhere in the heap ?

        I am genuinely interested. And I do think Mr Stroustrup is not totally honest.

        1. claimed Bronze badge

          Re: Really ?

          Rust does this via ownership, as others have explained. To get a pointer as an int and do fun/weird/dangerous stuff, you have to explicitly wrap the code in an 'unsafe' declaration, or it will not compile. At that point, all bets are off. Rust's guarantees only apply when you write normal/safe rust. If the programmer says "I'm smart, let me fuck about with integers, trust me bro"... then I hope they use other methods to validate their logic but the compiler is not going to. That's the awesome thing about Rust, if you never write unsafe code you'll never have these (specific) problems, and most applications do not require unsafe code, so the libraries that do require it can be small, audited, and hopefully bug free. But nobody is saying rust won't allow bugs, just that they will hopefully be less prevalent and always found in bits of code that label themselves as potentially dodgy.

          1. DrXym

            Re: Really ?

            I maintain a very large piece of code and I have a total of THREE unsafe blocks. All three of them are small blocks of code to do with a padding function I am in OpenSSL where it does stuff to memory buffers.

            That means if I suffer an NPE I know exactly where it is. The rest of the code which is tens of thousands of lines has no unsafe code at all although some of the crates undoubtedly do, mostly to wrap and call C and native OS APIs.

          2. fg_swe Bronze badge

            Referring to C++ Compiler

            I was asking how a C++ Compiler would do this. I think it cannot, because C++ does not have a memory safety system bolted-on.

            Something like a

            g++ --memorysafe

            switch. That switch would more or less turn the g++ into a SAPPEUR compiler. No more raw pointers, no more handing over arbirtrary pointers to thread functions, no more MT unsafe global data structures etc.

      2. DrXym

        Re: Better compilers?

        It's quite easy to enforce assuming all your code was C++ 20 in the first place and *only* using the safe constructs. Back in the real world C++ source code isn't like that and never will be.

    8. DrXym

      Re: Better compilers?

      The simple reason it can't be enforced by C/C++ compilers is because not a single C/C++ file would ever compile if they did. Nor do the languages give the compiler the contextual information necessary to enforce safety. Compilers could certainly get stricter by default, or do some lite static analysis but it's not going to hold a candle to what the Rust compiler would do by way of example.

      1. fg_swe Bronze badge

        Well

        There are plenty of smart people on the C++ standards committee. Maybe they will add a Memory Safety System to C++25 or so. The MSS would of course disable plenty of dangerous things and it would require additional syntax in order to delineate ST from MT datastructures.

        One could envision that MSS-enabled compilation units would even integrate with NonMSS compilation units. This would allow for incremental transformation of a code base towards memory safety. As I wrote many times, this is about incremental improvements, not Purity.

    9. mmstick

      Re: Better compilers?

      The aliasing XOR mutability concept in Rust requires syntax for assigning lifetimes to references, along with additional syntax for distinguishing between immutable and mutable references. It also requires that you are writing software using references instead of raw pointers. So in effect, no it is not possible and if you make the changes required to make it possible then you've just recreated Rust and most likely the duplicated effort is vastly inferior.

      That's also just one component of the feature set in Rust that makes it trivial to write software free of memory vulnerabilities. The other is the fact that move semantics are built into the language by default, with syntax to influence the behavior. Or that there's a trait mechanism to enable generics, and through that system there's some built-in traits that are automatically derived for types based on the composition of types within that type. Traits such as Send and Sync, which are used for thread safety mechanisms to prevent moving data cross thread boundaries that does not allow it, or preventing something from being shared across thread boundaries when it does not support it.

  3. Mike 137 Silver badge

    Best of all

    "Mitigations like address space layout randomization (ASLR) and stack guard are kind of a band-aid, not a full solution; moving to a memory-safe language is a much better one," added Reed

    No language is perfectly safe - each has it's own range of potential critical bugs -- they just differ between languages. So regardless of the language, the best protection of all is a combination of attention to detail and rigorous testing. Unfortunately both come expensive, so instead of allowing for that cost we've chosen to make successive languages more and more "de-skill proof", which just shifts the goalposts rather than making things inherently more secure.

    Just for example, it's quite possible to exhaust memory catastrophically in Java, despite its inherent memory management.

    1. Uffe Seerup

      Re: Best of all

      Vulnerabilities comes in classes. One such class is memory corruption vulnerabilities. These are particularly nasty because then can often lead to remote code execution.

      Some languages eliminate this class of security bugs completely. Garbage collected languages (e.g., C#, Java, Ruby) and borrow checking languages (e.g., Rust) are languages that eliminate memory corruption bugs.

      The advice is sound. Given that memory corruption often allows RCE, it makes sense to use a language where memory corruption is simply not a concern.

      1. fg_swe Bronze badge

        Thank You

        ...for this reasonable and kind comment.

      2. Anonymous Coward
        Anonymous Coward

        Big Caveat

        Java's memory access is heavily nerfed, at least at the programmer side, but the java vm itself is a seemingly bottomless font of security issues. So I'd hesitate pulling it's corpse of the burn pile and building new code with it.

        Yeah you can write insecure code in almost anything through your own mistakes or ignorance. The problem with Java is that the JVM can screw you over even if the code you wrote was rock solid. You can't build a strong castle on a cracked foundation. The JVM slowly turned into hot garbage over the years, succumbing to bitrot along with Flash.

        (Java still plainly the better of the two, clearly, but also not good, just less bad)

        Also at the end of the day, why suffer for it? Java's a dinosaur from anther time, the way it treats it's users is frankly insulting, and baked in insecurity is the reward you get for accepting handcuffs that make writing anything non-trivial in it a PITA. I'm all for shoveling dirt on it's smoking corpse. Any other takers?

      3. Frumious Bandersnatch

        Re: Best of all

        The advice is sound. Given that memory corruption often allows RCE, it makes sense to use a language where memory corruption is simply not a concern.

        But even rust grandfathers C/C++'s (what you might call) cargo cultism around order of execution (memory barriers and whatnot). The problem is that order of execution is a non-trivial (unsafe) problem where you're cribbing from C/C++, where your compiler can't check for non-compliance when it comes to translation of the standard, and the CPU can make up its own mind ...

        But yeah, in general Rust is a whole lot better. Just not perfect.

        1. ssokolow

          Re: Best of all

          I'm not sure it'd be fair to call it "cribbing from" so much as "doing the best they can when they didn't have the resources to reinvent LLVM or the clout to force it to change".

          1. Frumious Bandersnatch

            Re: Best of all

            Yeah, I agree. My objection against Rust was somewhat confected. I'm really a Rust fan, but I think that it's always good to preserve the "Reflections On Trust" Advocate position.

  4. xyz Silver badge

    Spy org says...

    Use these languages: trust us they're safe.

    1. Anonymous Coward
      Anonymous Coward

      Re: Spy org says...

      This shouldn't be overlooked.

      The NSA, Microsft and _you_ walk into a bar....

      Ultimately the joke ends with everything you want being replaced by what the NSA & MS want.

      1. ssokolow

        Re: Spy org says...

        Rust is open-source with a very public development process, so I doubt you'll find a better candidate for not getting backdoored by the NSA.

        Someone else characterized this as "the NSA has realized that trying to win at cyberwarfare by pure offense is ultimately a losing battle and has shifted to defense" and that makes sense to me.

        Remember that, at the end of the day, the NSA does believe itself to be acting in defense of the U.S.A., even if the road to hell can be paved with good intentions.

        1. Michael Wojcik Silver badge

          Re: Spy org says...

          And that an explicit part of the NSA's mission is to improve the US position against foreign SIGINT. That part was famously de-emphasized for a while around the turn of the 21st century, but under subsequent NSA directors and other Executive Branch influences became a priority again.

          The NSA considers itself pretty good at finding vulnerabilities and creating exploits. It doesn't mind raising the bar to make things harder for others.

      2. a pressbutton

        Re: Spy org says...

        The NSA, Microsft and _you_ walk into a bar....

        They buy you a beer

        "How did you know what I want""

        "We know..."

  5. Anonymous Coward
    Anonymous Coward

    Hmm, compiler and runtime checks on data and stack accesses, how very late 60s/early 70s. Of course they tended to be optional in those days due to hardware constraints (memory size, cpu speed) and you needed to add code to handle the runtime errors properly, so they were on the way out by the end of the 70s.

    1. fg_swe Bronze badge

      So

      ..Unix was the wrong turn, we should have gone the Algol Mainframe way instead !

      1. sitta_europea Silver badge

        Re: So

        "..Unix was the wrong turn, we should have gone the Algol Mainframe way instead !"

        I was gutted when they stopped supporting RTL/2.

    2. Dan 55 Silver badge

      As far as I know there are only two kinds of checks and you've listed them in your post. Are you advocating for no checks at all or some top secret unknown check no-one else knows about?

  6. Sceptic Tank Silver badge
    Go

    No Go =====>

    Butt C++ != C. Ok, so I don't write device drivers, or kernel code, or anything where a picosecond of performance loss will mean the demise of civilization. I'm pretty happy to use std::string and std::vector with iterators and the like for exactly the purpose of bypassing the memory manglement hell that C people have to live with, and having additionally have the opportunity to bask in some schadenfreude when I see it happen.

    C# is most certainly not immune to memory leaks.

    I'm surprised nobody used the opportunity to worship Python in this article. But then, that programming language was designed with the goal of making very bad programming mistakes built right in from V1.0.

    1. fg_swe Bronze badge

      Mixing Up Things

      You confuse Memory Leaks with Memory Safety. Please educate yourself. It is about stopping memory corruption and Virus Injection.

      1. Richard 12 Silver badge

        Re: Mixing Up Things

        C# is definitely not immune to memory corruption either, even assuming you're happy to accept a "stop the world" GC.

        The symptoms are really weird, too.

    2. sten2012 Bronze badge

      Re: No Go =====>

      Alright, I'll bite, what's wrong with python in this context?

      If Ruby is on the list, they are so bloody similar as to be nearly interchangeable.

  7. Anonymous Coward
    Anonymous Coward

    Crap unsafe software can be written in any language...

    ..its always the programmers, never the language, that is the reason for insecure software. Totally locked down software can be easily written in asm. By a competent programmer.

    And there have been tools to find exactly these kind of problems in C and C++ codebases for at least 30 plus years.

    There again, the more secure the general software ecosystem the more valuable the NSA's hardware backdoors are. Its not just in certain CPU's you know..

    1. fg_swe Bronze badge

      Yeah, Nihilism

      ..always helps to stay in the darkness of ignorance. You use it with an additional tinfoil hat.

      1. Anonymous Coward
        Anonymous Coward

        Re: Yeah, Nihilism...read any CPU hardware manuals lately?

        Well if you have been reading the CPU hardware manuals since the late 1970's (some of us have to worry about instruction clock cycles, cache miss penalty, decode depth per IPU etc.etc) you would have noticed some very interesting "features" mentioned in the mid 1990's for a certain CPU that have since disappeared from those multi K page tomes. Wont go into details but if you have been reading motherboard schematic for all these decades (since the days of 74LS TTL's) and know exactly whats connected to what and why, and what those timing diagrams mean. and what every last bit in all those system registers means, well, there are some very interesting things to find in those very old CPU hardware manuals which explain some of the odder elisions in the newer ones.

        To those of us who actually had to totally lock down and secure executable environments, software and hardware, for commercial products our interest tends to be piqued if we see a very odd several line paragraph tucked away among the several K pages of a CPU hardware manual. Especially if the paragraph disappears in the next and subsequent editions but the "feature footprint" does not.

        In those secure execution environment products the hardware and the OS are the primary attack surface. Which is why you have the source code / disassembly and all the relevant hardware manuals. No matter how obscure the chip. Plus you keep a logic analyzer around. Just in case you need it. But I usually leave that to the triple E's.

        I'm sure there was nothing to the MS Anti Trust settlement being essentially set aside in 2001 for "national security reasons". Or the mystery of why the network stack codebase was never part of the 3'rd party build set. Nothing to see here, move along...

        You do know that your shiny new language compiler is just yet another attack surface? That compilers have bugs. Lots of them. I can verify and validate the output from a subset of C fed into any C (but not C++) compiler. I have yet to see a compiler for any language that with a little playing around with, and looking at the output disassembly, you cannot find a compiler bug that provides some nice juicy exploit hole.

        Your shiny new language will not protect us from crap programmers writing crap code. Who usually work for Big Nasty Software Corp Inc. In my experience.

    2. Mr D Spenser

      Re: Crap unsafe software can be written in any language...

      Full disclosure, I am not a Rust programmer or pretty much any sort of programmer anymore (JAPH).

      However, in the documentation it does explain how to get around some of those pesky memory checks and gain "superpowers" when you know you are right and the compiler is wrong.

      https://doc.rust-lang.org/book/ch19-01-unsafe-rust.html

      So yes, "Crap unsafe software can be written in any language"

      1. fg_swe Bronze badge

        Exceptions From Rules

        As much as the fire brigade can break rules of the road under pressing circumstances, low level software components will need to be excepted from memory safety.

        As with the blue lights and the siren, this must be done in a controlled and careful fashion. Just because you have the siren blaring, does not mean you can run over a crossing. You (as a fire brigade driver) better go slow, check the traffic and then do the crossing.

        If this is done correctly, the risks are controllable and acceptable. It does not mean there should be no rules of the road, because the police, fire brigade, red cross must break them then and now.

        1. fg_swe Bronze badge

          Real Example

          int Socket::send(&char buffer[],int count)

          {

          var int ret;

          if(count>buffer.sz)

          {

          return -2;

          }

          inline_cpp[[

          ret=0;

          while(ret<count)

          {

          int ret2;

          if( tlsConnection == NULL )

          {

          ret2 = ::send(_handle,buffer._array+ret,count-ret,0);

          }

          else

          {

          ret2 = tls_write(tlsConnection,buffer._array+ret,count-ret);

          }

          if(ret2<=0)

          {

          return -1;

          }

          ret=ret+ret2;

          }

          ]]

          return ret;

          }

          1. druck Silver badge

            Re: Real Example

            Not heard of the pre and code tags?

            1. fg_swe Bronze badge

              Thanks

              will do next time.

      2. DrXym

        Re: Crap unsafe software can be written in any language...

        Rust is safe by default. You'd have to be determinedly bad at programming to want to wrap everything in unsafe for no reason. The purpose of unsafe in the language is for interface boundaries with the operating system or other languages. e.g. to call a function in C, or to be called by C.

        1. fg_swe Bronze badge

          Plus

          ...the senior engineer should review every single "unsafe" or "inline_cpp" instance for correctness and conciseness. Whenever a new one is inserted or a change is made, it is time for a diligent review and prolly also new unit tests just for this piece of code.

    3. DrXym

      Re: Crap unsafe software can be written in any language...

      The difference is a crap programmers and crap software get a lot further in C or C++ than they should. If you write crap in Rust the compiler will kick your ass and then helpfully explain why it's not going to compile your code. In C/C++ the compiler won't care and that bug might go all the way to production which not only degrades the quality of the code, puts security at risk and makes it harder to identify and fix after the fact.

      This is why the NSA and others are pushing hard on using a safe languages.

      1. fg_swe Bronze badge

        Re: Crap unsafe software can be written in any language...

        Fix: "The difference is a 99,999% of programmers and their software get a lot further in C or C++ than they should."

  8. This post has been deleted by its author

    1. fg_swe Bronze badge

      Greetings

      I salute my computer science colleagues in Military Intelligence for supporting the trend towards Memory Safety.

      Having invented a memory safe language

      http://sappeur.ddnss.de/

      myself, I am very pleased to be validated by this esteemed* computer science organization.

      Memory Safety is the natural progression from firewalls to mandatory access control (SE Linux, AppArmor, sandboxing) to fine-grained Software Fault Isolation.

      Applied computer science does have a big problem, which is a lack of practical security. Entire corporations have seen their computer networks destroyed by exploits which are based on a lack of C or C++ memory safety.

      http://sappeur.ddnss.de/Sappeur_Cyber_Security.pdf

      70% of CVE exploits are based on the lack of memory safety of real-world C and C++ programs. Let's plug this hole.

      Let's rediscover the Algol Mainframes, Spark ADA, Modula-2, Oberon, MSFT's Singularity OS. Memory Safety is not a new idea, but it had been forgotten.

      * see the Perl Language as an example of NSA inventions

      1. TimMaher Silver badge
        Trollface

        Re: http://sappeur.ddnss.de/Sappeur_Cyber_Security.pdf

        My browser will not navigate to that because it is insecure.

        1. fg_swe Bronze badge

          Re: http://sappeur.ddnss.de/Sappeur_Cyber_Security.pdf

          Oh yeah, unsafe because not using 400Kloc of OpenSSL niceness ?

          1. Grogan Silver badge

            Re: http://sappeur.ddnss.de/Sappeur_Cyber_Security.pdf

            Don't even try to argue with these parrots.

      2. runt row raggy

        Re: Greetings

        Larry worked for NASA, not the NSA. there's a bigger difference than the single letter would imply.

        1. fg_swe Bronze badge

          Re: Greetings

          Apparently, he worked for BOTH NSA and NASA

          https://blog.techno-z.at/larry-wall-i-can-do-better-i-know-how-to-write-a-computer-language/

          Perl clearly is an NSA thing (agile extraction of needles from a haystack) as opposed to NASA (numerics).

  9. fg_swe Bronze badge

    Empirical Results Of Memory Safety

    To all the detractors, I would like to point out this:

    A) Decades-old Unix tools have been run with valgrind and exposed memory errors. So they still had memory errors after 1000 incremental bug fixes.

    B) Even in safety critical automotive embedded code, programmed by highly experienced (20 years or more of software engineering time) software engineers, we find index errors using tools such as PC Lint or PolySpace.

    C) Working with memory safe languages results in less pain, less bad surprises in my work as a software engineer. I am developing software since 1993 and I have a degree in CS.

    D) Tony HOARE points out that real-world, production(!) FORTRAN programs typically contain index errors. Turning on index checking "offended" the FORTRAN users, because it "broke" their "proven" programs.

    Conclusion: Human software engineers are the best we have (artificial neural networks can't do it yet and prolly won't do for another 100 years) and they are NOT perfect. Claiming such perfection is equivalent to lying.

  10. Will Godfrey Silver badge
    Meh

    Maybe I'm missing something

    But how does memory safety reduce phishing attacks, DDOS or plain old hard-coded passwords?

    Can we get our priorities right?

    1. fg_swe Bronze badge

      Multifaceted

      I.T. Security has many aspects, one of which is Software Fault Isolation a.k.a. Memory Safety.

      A single programming error should not open up the castle for an attacker.

      That does not mean other aspects can be ignored.

      It is called Computer Science, because it is not a trivial thing.

    2. Anonymous Coward
      Anonymous Coward

      Re: Maybe I'm missing something

      You are right that those are important parts of the attack surface, but this isn't an either or proposition. Using programming tools that are more memory safe are a part of the solution that falls on most people writing code.

      Those that work on parts of these systems that face the classes of attacks/problems you mention have additional things they need to address, but they will need to do both, not choose one or the other. (though not the passwords thing, anybody that does that is a monster and should be fed to a mob of angry village people)

      Memory save languages make the job of consistently avoiding these errors easier, even if things like rust bring a little pain and learning curve. And as one of the other posters above implied, if you think you can do that every time on your own in C and never slip up, you are lying to yourself. The code profilers strongly suggest otherwise. So why, other than pride or routine,would I stick with using tools so prone to blowing my own feet off?

    3. SCP

      Re: Maybe I'm missing something

      You must be an Englishman as you are embodying what Babbage railed against ...

      "Propose to an Englishman any principle, or any instrument, however admirable, and you will observe that the whole effort of the English mind is directed to find a difficulty, a defect, or an impossibility in it. If you speak to him of a machine for peeling a potato, he will pronounce it impossible: if you peel a potato with it before his eyes, he will declare it useless, because it will not slice a pineapple."

      :-)

      It is worth keeping in mind the aphorism "Perfect is the enemy of good" - the suggestion from NSA does not address all problems, but it does address a recurring problem in "everyday" software.

    4. DrXym

      Re: Maybe I'm missing something

      Your question makes no sense. Safe languages are intended to stop exploits and instability caused by C/C++ like buffer over/underflows, race conditions etc. No language to my knowledge can stop code from making general application logic errors but neither the NSA or the safe languages themselves are even claiming they can.

  11. Rich 2 Silver badge

    C underpinnings

    But languages like Java and JavaScript (I use the term “language” loosely here) and probably (I admit I’ve not checked) Go etc etc are either written in C or use massive C libraries underneath

    So, that knackers up the supposed memory security “guarantee” (yea - right!) straight away

    1. fg_swe Bronze badge

      Negotiate

      "You can negotiate with a terrorist, but not with a computer guy".

      Seriously, you should discover that there is more than just black and white. Real technology progress is about gradual change as opposed to ideological purity.

      1. Rich 2 Silver badge

        Re: Negotiate

        I was just pointing out the folly of advocating a solution that has (by the advocate’s own argument) an underlying basic and catastrophic flaw.

        Unless you can absolutely verify that the underlying implementation of the tools is flawless then you are building on sand.

        Of course, we build on sand every day because very few people outside of academia and computer research bother to verify that the tool chains we use are flawless (or even close).

        1. fg_swe Bronze badge

          No

          My Sappeur compiler(coded in C++, but could be self-hosted one day) is far from perfect, but it has found lots of programming errors for me. The resulting code is empirically much more robust than equivalent C++. Much less "inexplicable" behaviour.

          That is my experience, believe it or not.

        2. Anonymous Coward
          Anonymous Coward

          Sooo, no.

          While the first versions of any language compilers are by necessity written in another tool (or assembly), many have been rebuilt on their own code after the language is feature complete and stable. Hence modern C compilers are compiled using other c compilers and not assembly or COBOL.

          The flaw you are arguing is in your own logic unfortunately. You conflate the classes of problems that the compiler could cause with the classes of problems the language is prone to. You also imply that the tools must be "flawless", which is nonsense. Yes, the sum of the problems in the underlying tools and runtime(in runtime languages) and the problems in the code itself all end up in the output. But perfect code beyond specific or trivial cases is provably impossible. The eminently achievable goal is to REDUCE the number and severity of problems. That's not building on sand. More like bricks, and one cracked brick will rarely bring a building down, especially if the engineers are paying attention.

          Verifiably "flawless" code is only possible under specific constraints, and is impossible in a general sense, and also once you factor modern hardware in. QA exists for a reason though, so even when you can't write a formal proof of correctness, you can still do a good job. And good programmers need to understand whats happening inside that box that represents the compiler to manage any problems that may impact their code.

        3. SCP

          Re: Negotiate

          I was just pointing out the folly of advocating a solution that has (by the advocate’s own argument) an underlying basic and catastrophic flaw.

          And C [and other] compilers have code generation flaws, but that does not make using High Order Languages (for some value of High) a bad decision or reduce us to "building on sand" - though we need to remain cautious about the degree of trust we place in such things.

          The key difference between writing software in a language that exposes a greater risk of errors, or using a language where some underlying part of the toolchain is still dependent on that riskier language, is that the former approach exposes the entirety of the new software to those risks (and there is a long and sad history of software writers continuing to make the same sorts of mistakes as has been happening for decades). The latter approach moves more towards the "Correctness by Design" model in which it is not possible (or at least diificult) to make these mistakes during the implementation process.

          It remains a problem that tools such as compilers (or libraries) might introduce errors - which is why you need to remain careful about the degree of trust you place in them (e.g. by careful vetting and control of your choices, and the degree of testing of the final product).

          1. fg_swe Bronze badge

            Thanks

            I find it very hard to reason with some fellow software engineers, who argue like religious nutcases. To them, only Total Purity is acceptable. Black and White.

            Thanks for trying to explain to them that less-than-pure improvements can still be important improvements.

    2. runt row raggy

      Re: C underpinnings

      go is implemented in go, and does not use c libraries by default.

    3. fg_swe Bronze badge

      Self Hosting

      Any Turing-complete language can be self-hosted. Whether that provides value, is not always clear.

      There are plenty of self hosted compilers out there: Pascal, Algol, Ada, Modula2, ...

      1. Strahd Ivarius Silver badge
        Angel

        Re: Self Hosting

        but how is a self-hosted compiler compiled in the first place?

        1. Chris Gray 1

          Re: Self Hosting

          Ah yes, the need for bootstrapping!

          My solution to that issue has been to maintain compiler sources in *both* languages. For a lot of stuff, I write in my own language first, since it is higher-level than C, then translate to C (yes, manually) when the former first compiles.

          Over time, significant chunks of the C code have been deleted, replaced with calls to my bytecode engine to execute the version in my own language. At some point, my system will be complete enough to fully compile itself.

          I was pushing to have versions of the whole thing quite a while ago, but stopped. As the language changed, there was no good reason to keep redoing the parser, for example. I did do the lexical scanner, and have used it to good effect for other purposes.

          Currently, I'm working on producing X86-64 code (mostly there now) and Elf files to run on Linux. All of that is *only* in my own language.

          Will my compiler end up as "good" as gcc or llvm? No, of course not. One guy versus teams of people. However, having *all* of the needed tools written in a memory-safe language will, I believe, be of benefit for extremely critical situations.

          1. Anonymous Coward
            Anonymous Coward

            Re: Self Hosting

            ...and then there's the so-called Ken Thomson hack (circa 1974):

            - https://wiki.c2.com/?TheKenThompsonHack

            Do you "trust" the C compiler you are using?

            Or perhaps you have adjusted the C compiler to suit yourself?

            I think we should be told!!

            P.S. This isn't a theoretical attack.....the SolarWinds mess used something similar!

            1. fg_swe Bronze badge

              Re: Self Hosting

              A little bit of assembly level inspection would expose this.

              Plenty of embedded sw organizations look at generated assembly, some even line by line source+assembly. Life critical aerospace control, for example.

              Plus, there exist automatic protocols to.expose this technique, IF you have a single untainted compiler+os+machine.

            2. ssokolow

              Re: Self Hosting

              I usually hear it referred to as a "trusting trust attack" and one strategy for countering it is Diverse Double Compiling (https://dwheeler.com/trusting-trust/).

              Since Rust doesn't yet have a second full compiler, their approach for countering that attack is:

              1. Use DDC to get a trusted-to-be-clean C++ compiler

              2. Use mrustc (https://github.com/thepowersgang/mrustc) to bootstrap whatever the newest version of rustc it supports is from C++. (Currently 1.54.0. mrustc is a C++-based Rust compiler meant specifically for re-bootstrapping rustc, which keeps its complexity down by just trusting that what it's compiling would pass borrow-checking under the full compiler.)

              3. Use the resulting compiler to bootstrap-chain up to the current Rust compiler.

              Every time it's been done so far, the hashes of the produced rustc binaries have matched the hashes of the rustc binaries that trace their lineage back to when rustc was originally written in Ocaml.

        2. Claptrap314 Silver badge

          Re: Self Hosting

          https://users.ece.cmu.edu/~ganger/712.fall02/papers/p761-thompson.pdf

        3. SCP
          Happy

          Re: Self Hosting

          Using Forth

  12. xyz Silver badge

    I used to have an NSA coffee mug...

    But I threw it away when I realised the ceramic was chipped...

    Seriously!

    1. stiine Silver badge

      Re: I used to have an NSA coffee mug...

      A microwave would have saved you the hassle.

  13. karlkarl Silver badge

    "NSA urges orgs to use memory-safe programming languages"

    This translates to:

    "NSA urges orgs to spend their time writing and maintaining bindings rather than writing software"

    Perhaps true. After all, the less actual useful code written means the less chances for problems to occur.

    1. fg_swe Bronze badge

      Well

      Sappeur is translated to C++ and allows you to directly call C or C++ wherever you need that.

      Keyword inline_cpp

      No need for complicated bindings.

      1. karlkarl Silver badge

        Re: Well

        It doesn't deal with marshalling of data types; typesafe callbacks, lambdas, memory lifespan and ownership.

        This will all need to be done manually. The language is too complex for binding generators. Things like Swig can only do so much.

        1. fg_swe Bronze badge

          OK

          So I should write "Sappeur nicely and easily integrates with C++".

  14. Anonymous Coward
    Anonymous Coward

    Languages will never protect us from lazy and stupid programmers..

    Its many decades since I ran into a buffer underflow / overflow bug in any code I have written. In fact Reagan was president at the time of the last bug, in my first really big commercial product codebase.

    Dont want buffer / array bugs then follow a few very simple rules.

    1) Dont allocate on the local stack or the globals space. Always in the malloc() memory heap.

    2) Always as a struct where first fields are maxsize in bytes, max array element count, then the buffer, array data

    3) Every read and write uses an accessor function to this struct which checks min, max, range values and only if everything is legal does it proceed.

    Another rule that will save grief down the line, dont use for loops anywhere for accessing data in buffers / arrays. If the codebase is used enough the for loop will fail, somehow. Same goes for anything recursive. Where are those function call stack frames kept in memory. What happens when that OS stack frame partition for your process is full? That sort of stuff.

    Plus if every third or fourth line of the source code is not an assert of some sort of other then the code will fail. If given enough time.

    Thats what actual engineering looks like. A lot of error checking and a huge number of asserts and only continue if all correct code. If the code is not written on the assumption that something might fail, totally paranoid code, the code will fail. If used enough. Guaranteed.

    1. fg_swe Bronze badge

      FALSE

      Apparently you work in accounting, web programming or the like.

      There exists software which is - for all practical purposes - perfect:

      ABS Brakes

      ASR

      ESP

      Airbus A320 and later Flight Control SW

      JÄGER90 Flight Control SW

      Space Shuttle Flight Control SW

      If this software were not perfect, we would have seen spectacular crashes and dead people. We have seen that with GRIPEN, F22, V22, 737MAX, ARIANE V, but never with JÄGER90, A320, A330, A340, A380 or A400M.

      And of course AIRBUS, BOSCH, Continental etc use much better software engineering processes than YOU have ever seen.

      1. fg_swe Bronze badge

        Re: FALSE

        https://de.wikipedia.org/wiki/Eurofighter_Typhoon#Zwischenfälle

        https://de.wikipedia.org/wiki/Lockheed_Martin_F-22#Zwischenfälle

        "Im April 1992 stürzte der erste YF-22-Prototyp im Landeanflug auf „Edwards“ ab. Testpilot Tom Morgenfeld überstand den Absturz unverletzt. Untersuchungen ergaben, dass die Flugzeug-Software Pilot Induced Oscillations nicht oder nicht hinreichend entgegenwirkte.[133]"#

        F22 control creates oscillations:

        https://www.youtube.com/watch?v=mbQx89Eklm8

        Gripen control algorithm issues:

        https://www.youtube.com/watch?v=k6yVU_yYtEc

        V22 has an own page for the 51 people it killed out of enemy action

        https://en.wikipedia.org/wiki/Accidents_and_incidents_involving_the_V-22_Osprey

        1. fg_swe Bronze badge

          Proper Engineering

          If you want to see how proper R&D looks like, look how Suebi(with a bit of British help and an American Pilot) do it:

          https://www.youtube.com/watch?v=AkdvKfiaEeg

          Noone killed, and better performance( speed, payload, range) than ANYONE since 1970. Nobody comes close.

      2. Anonymous Coward
        Anonymous Coward

        Re: FALSE..Really?.. you havent a clue...

        Let me guess. You have never actually shipped any meaningful software. To end users. Of worked with anyone who has. Maybe at best just a small time byte pusher on a very large bureaucratic dev team working on Big Corp / Big Gov projects.

        I was shipping mass market software (100K's to 1M's+ users ) long before you were born by the sound of it. I was the guy who had to sign off on the Golden Master on very expensive production runs when thats how software was delivered. Get even simple stuff wrong, that's many $100K's of disks / carts straight to landfill. This was back when you could buy a very nice car for $15K.. Get it seriously wrong and you are out of business in 12 to 18 months..

        The last product I shipped was download only, but 600K downloads in the first 3 days, over 3M in first 90 days. For a very big company whose products you own and who care very very much about quality and company reputation. Nothing like a few million users to show up low probability serious bugs very quickly. That final Release Master put up on the server had to be even higher quality than what we used to send out as GM for dup. As any failure would be more obvious, more quickly.

        I've have also worked on teams with guys who wrote avionics software for Boeing (FAA certified commercial aircraft) , missile control software for Lockheed Martin (the stuff that makes very big bangs when it lands 8000 miles away), and worked on embedded software (lead) that has go through FDA certification. So I know exactly how that software is written, the methodologies involved, and heard the war stories from the trenches. Some real doozies. Also the heard war stories from the NASA guys. Both Shuttle and Deep Space probes. The real miracle with the Shuttle is they only lost two hulls.

        Funnily enough I fitted right in with the Boeing and Lockheed Martin guys. In fact my code was safer than the stuff they wrote. I actually had worked through potential point of failures for all language elements. For a guaranteed full recovery / restart on fail soft real-time OS project a few decades ago.

        I'm old enough to remember exactly why both provable ADA compilers and other provably software efforts failed. And why very strict code discipline enforced by the dev lead actually works. Unlike the purely box ticking exercises for the latest ISO xxxx bullsh*t. by PM's.

        You should get out more. Or maybe stick to stuff you might actually have a clue about.

        1. fg_swe Bronze badge

          Indeed

          1.) I worked on automotive software which is successfully used in hundreds of thousands of cars, some of which is ASIL D at max (maybe you use it in the power steering in your BMW, Tesla or Mercedes, maybe you use it in the VW Camper)

          2.) Your experience at US aerospace companies validates my point that US aerospace projects are dangerous affairs. The V22 is just the tip of the iceberg. Below we can see F22 and 737MAX.

          3.) I suggest you guys on the other side of the pond learn what V-Model development REALLY means. First and foremost, it is about honesty and about "reaping the low hanging fruit first". Have realistic Unit Tests, don't do something fox box-ticking, have realistic HIL tests. I bet your managers are cheating on all of it in the name of "financial performance".

          3.2) Having said that, I also know German+other European managers who like to cheat, but apparently on average it is not as bad as in the U.S.

      3. Anonymous Coward
        Anonymous Coward

        Re: FALSE

        > There exists software which is - for all practical purposes - perfect:

        > ABS Brakes

        You clearly never experienced the joy of the Subaru ABS software, which contained a bug known to owners as "Ice mode". Once it gets into that state, there is no braking at all and you don't stop until you hit something.

        Of course, the brakes don't lock up, so technically it meets the specification.

        1. fg_swe Bronze badge

          Japanese Embedded

          There are some indications that they were seriously challenged in the past to do proper SW engineering in automotive. I would assume though, that all of that has been resolved by now.

          We have excellent relations with both Japan and South Korea and they will understand that they must meet high standards for selling cars in the US and Europe. Just recently we sent 6 JÄGER90 to Japan in order to stiffen their defence against China. In Return they wil definitely listen to our concerns.

  15. Anonymous Coward
    Anonymous Coward

    How many new projects are that could be written using a GC-enabled language, but will be written in C/C++ instead if it were not for security concerns?

    None, maybe. All those GC-enabled languages are much easier and faster to work with, and easier to debug. But are not suitable for RT processing.

    So it boils down to C/C++ vs Rust for those projects where a GC-enabled language is not suitable.

    1. fg_swe Bronze badge

      Also: Economics

      GC-based runtimes typically consume twice the RAM of an equivalent C++ or Rust program. Each memory cell consumes power and generates heat. Some applications are constrained by power and heat dissipation. E.g. aerospace, satellites,...

  16. Slipoch

    Irony

    This coming from the org that used one password (total) for all it's staff to access all it's spyware toolsets?

    Not to sound paranoid, but it is also a LOT easier to reverse engineer or snoop GC/Memory-Safe applications, particularly while they are running. A lot easier than native machine code etc.

    1. fg_swe Bronze badge

      Re: Irony

      If they really need your passwords, a micro camera in the ceiling will do that. Are you a criminal ?

  17. 10111101101

    The irony all of those suggested languages are written with C/C++

    1. fg_swe Bronze badge

      All of them could have their compilers or interpreters written in Ada, too.

  18. rmstock

    NSA ?

    Why would the largest spy and surveillance organization in the world, the 5-eyes mammoth, be pushing a thing called Rust ? Who controls Rust ? Does Rust have some nasty stuff embedded inside, which can trigger unsolvable exploits ? "New security update : install new build of Rust, fixes 26 security errors immediately." Is Rust adopting the Google Chrome model of peddling zero day exploits in new builds ? With C/C++ there's apparently no such market possible for the dark net dragons.

    1. fg_swe Bronze badge

      Re: NSA ?

      I suggest you fasten the tinfoil hat and randomly check the generated assembly code. I am quite sure you will find nothing nefarious, as other people would have found stuff before you and blew the whistle.

    2. DrXym

      Re: NSA ?

      Yeah it's all a vast conspiracy. I think you should program in machine code. Not assembly language but machine code bytes. On a 6502 salvaged from a C64. Just in case the NSA has put hooks in modern processor's microcode .

  19. EnviableOne

    stop Blamimg C / C++

    it's not C's fault people are using it for stuff it's not supposed to be used for

    it's an ultra-low-level language designed for those applications, ie single core applications running at highly efficient speeds on highly limited resources, where you need to control the memory space and re-allocate it to get the required performance or capability from the limited hardware.

    if you don't need to use C/C++ then don't use it, if you do, you make your trade-offs and know how to make it work for your situation.

    1. fg_swe Bronze badge

      Yes

      That is what NSA says: use memory safe languages whenever feasible.

  20. kirk_augustin@yahoo.com

    Totally Backwards

    All the programming languages listed, like "C#, Rust, Go, Java, Ruby or Swift", are terribly insecure, as well as being much slower and limited.

    All of them require installing run time security breaches that can easily be exploited.

    None of the secure facilities I have ever worked at would ever allow a Java interpreter engine be installed for example, because then it is easily controlled by anyone who knows the details of the built in vulnerabilities.

    C and C++ are the MOST secure languages because they rely on loading the fewest run time leaks, and are totally self contained except for driver and OS calls.

    This article should have known better, and any real programmer should know that C and C++ are by far the most secure programming languages.

    About the only security weakness in C and C++ are buffer over runs, which should be caught by the OS calls.

    1. fg_swe Bronze badge

      SAPPEUR

      I suggest you use this memory safe C++ variant:

      http://sappeur.ddnss.de/

      You can always check the generated C++ code for NSA backdoors. I have a secret contract with NSA and will only insert backdoors after you have used the compiler for more than 16 hours during the last 24 hours. Then I assume you are too tired to check and will insert the backdoors.

      If you purchase my high performance tinfoil hat with the compiler(see below), I promise not to insert any backdoors.

      Seriously, man, get yourself a bottle of beer and a serious touch from your girlfriend.

  21. kirk_augustin@yahoo.com

    NSA wants more back-doors

    Obviously these languages the NSA are promoting, like "C#, Rust, Go, Java, Ruby or Swift" are the least reliable and secure, because the NSA does not want "security", but instead want more backdoors they can more easily exploit.

    1. fg_swe Bronze badge

      Re: NSA wants more back-doors

      As a side business I sell high performance tinfoil hats and specially for you I can give you a 70% discount. Just 300 Euros. Deal ?

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Other stories you might like