back to article FreeBSD 13.0 to ship without WireGuard support as dev steps in to fix 'grave issues' with initial implementation

A faulty implementation of WireGuard, a high-performance VPN protocol, has been removed from FreeBSD 13.0, shortly to be released, and a new implementation will not ship until the arrival of 13.1. WireGuard, created by Jason A Donenfeld, was among the most warmly anticipated new features in FreeBSD 13.0. Netgate, sponsors of …

  1. HCS

    Dig deeper than this story. Netgate has a history of stepping on it's own peepee and when it gets called out it acts like it did nothing wrong...everybody else is attacking them...and they are simply trying to help. the fact of the matter is..netgate tried tor release crappy code that exceeds the poor quality of most software these days...the project maintainer called them on it..and netgate went whining to the internet. Get over it Netgate...hire a competent engineer and work with the wireguard project maintainer.

    1. Anonymous Coward
      Anonymous Coward

      To be honest the description of the code in the article...

      There were random sleeps added to "fix" race conditions, validation functions that just returned true, catastrophic cryptographic vulnerabilities, whole parts of the protocol unimplemented, kernel panics, security bypasses, overflows, random printf statements deep in crypto code, the most spectacular buffer overflows, and the whole litany of awful things that go wrong when people aren't careful when they write C.

      ... looks like just the kind of outsourced code that I have the pleasure of working with (which means fixing it after it blows up in live). And as in the article it just appears in the source tree one day with a ticket number and if you open the ticket there's nothing that says how or why.

      Someone will be along in a moment to blame C for all that, by the way.

      1. Anonymous Coward
        Anonymous Coward

        re: Someone will be along in a moment to blame C for all that, by the way.

        I aim to please.

        You say that like C isn't behind the vast majority of vulnerabilities and exploits, but it is.

        If it's so difficult to write C well then surely some of the fault must be with the language.

        "Programs must be written for programmers to read, and only incidentally for machines to execute." - Abelson and Sussman, Structure and Interpretation of Computer Programs

        C is the tail wagging the dog.

        1. Phil O'Sophical Silver badge

          Re: re: Someone will be along in a moment to blame C for all that, by the way.

          If it's so difficult to write C well

          It isn't. Problems like:

          random sleeps added to "fix" race conditions, validation functions that just returned true, catastrophic cryptographic vulnerabilities, whole parts of the protocol unimplemented, kernel panics, security bypasses, overflows, random printf statements deep in crypto code

          are just bad coding, no matter what the language. "sleeps to fix race conditions" FFS? What sort of crappy junior-school coder thinks that's a solution?

          the most spectacular buffer overflows

          OK, that's easy to do in C if you're not paying attention, but there are functions you can use to avoid it, and test tools to catch it.

        2. nautica Bronze badge
          Boffin

          Re: re: Someone will be along in a moment to blame C for all that, by the way.

          "...If it's so difficult to write C well then surely some of the fault must be with the language..."

          What an absolute crock of shit. Talk about convoluted logic! Here's a big clue, Sherlock: writing EXCELLENT CODE in any language is exceedingly difficult. Time to change professions...

          If it's so difficult to lay bricks well then surely some of the fault must be with the bricks...

          1. Anonymous Coward
            Anonymous Coward

            Re: Time to change professions...

            I'm about 10 years from retirement, been doing this for 30+ years, I'm ok thanks.

            And unlike you, I'm not triggered by someone pointing out that the language I love is a bit pants.

            Look at the data to decide whether the language is shit. You know, science and that.

            "But it's possible to use it properly if you're really careful" is no reason for using a shit tool.

            1. John Brown (no body) Silver badge

              Re: Time to change professions...

              EXactly this. Back in the days before Heath & Safety, even craft Masters gor maimed or killed by their tools, never mind the apprentices and journeymen. Then H&S got involved and added safety guards etc.

              Having built in safety measures doesn't stop you creating shit, but it's likely to be safer shit.

            2. Mobster

              Re: Time to change professions...

              Bugs in critical code written in _any_ language will be critical bugs. As it happens, the World uses C heavily for critical system level items of code, so C ends up with the blame for many critical problems. Haskell, Julia, language du jour, would get the same reputation if one could write system code in it.

        3. nautica Bronze badge
          Holmes

          Re: re: Someone will be along in a moment to blame C for all that, by the way.

          "‭The amateur software engineer hack is always in search of magic, some sensational method or tool whose application promises to render software development trivial. It is the mark of the professional software engineer to know that no such panacea exists."--paraphrased from Grady Booch, in "Object-Oriented Analysis and Design with Applications"

        4. Anonymous Coward
          Anonymous Coward

          @AC - Re: re: Someone will be along in a moment to blame C for all that, by the way.

          Remind me who's always blaming his tools ?

          1. Anonymous Coward
            Anonymous Coward

            Re: @AC - re: Someone will be along in a moment to blame C for all that, by the way.

            There's a saying where I'm from, translated:

            The incapable dick will blame the (pubic) hairs about his performance.

          2. Anonymous Coward
            Anonymous Coward

            Re: Remind me who's always blaming his tools ?

            I don't code in C.

            I just read about vulnerabilities.

            I never read about other languages.

        5. Charlie Clark Silver badge

          Re: re: Someone will be along in a moment to blame C for all that, by the way.

          It's not difficult to write good C code. But, it's important to know how the language works and which domains is suitable for and which domains it's not. It is a lot less forgiving than many other languages and this is where most programmer errors occur. It's an excellent language but often requires the kind of mindset of a precision engineer to do write.

      2. CheesyTheClown

        I was about to

        sweep in and complain about poor coding.

        Whenever I write kernel modules in C (Linux ugh), I find myself spending far too long detangling unintuitive preprocessor crap that has no place in 2021. When implementing secure protocols, most ciphers allow in-place operations, but usually headers need to be prepended and you will never find a solution to this problem that permits for the headers to remain memory aligned or for the buffers to be encrypted do.

        This means to effectively make protocols which encapsulate higher level data, good buffer management is necessary. And while C allows you to do anything you want, as efficiently as you want, almost all solutions to the problem tends to lead towards reimplementing object oriented language features... usually in preprocessor macros or using crazy compiler extensions for tracking offsets into buffers based on their positions in structs.

        There is also the whole game of kernel buffers. Since the kernel is in privileged mode, performing allocs and frees is frowned upon. The structure of the kernel memory space is expensive and dangerous to randomly allocate memory, especially if it may trigger the kernel to need to further allocate memory beyond its initial pool. Since the MMU is mostly bypassed in this mode and since C memory management generally is not relocateable, the only real solution is to overprovision needlessly.

        I could (and probably should) write a book on all the numerous problems related to kernel development as well as the endless caveats of coding kernels in C, but let me simply say that while good C code is possible, it’s rare and far too many trivial tasks are managed manually and repetitively when coding C.

        I don’t particularly care for the syntax of Rust or Go. But both languages run with a great concept which is... if it’s a very common task that can be added to the language with no real additional cost, do it. As such, both languages understand strings, buffers and data structures. There is no need for disgusting hacks to implement things like macros that are all hacks to support something as trivial as foreach.

        C could fix these things as well. But it’s a conscious decision by the people steering the language to keep it as it is and to leave it to libraries and compiler extensions to do it instead.

        I love C because if I want to write a new C compiler, I can make something usable and likely self-hosting within a few hours. But this isn’t the characteristic of a programming language I would want to use in 2021. If I were to spend my time on such a project, the first thing I’d do is build extensions for strings, buffers and data structures ... and it wouldn’t be C anymore.

        Oh... and most importantly, I would drop the preprocessor and add support for domain specific language extensions. And I’d add proper RTTI. And I’d add an extension for references. And of course relocatable memory. And probably make ...

        You know what... I don’t think I’d do anything other than bootstrap the new language with C and then basically just ignore the standard from there :)

        1. Phil O'Sophical Silver badge

          Re: I was about to

          You're conflating "things that are hard to do in a kernel" and "things that C doesn't do well".

          Any good kernel implementation will have kernel memory allocation/free functions that are safe to use, and just because a concept has been added to a new language to hide such mechanisms doesn't necessarily mean it's usable in kernel mode. If the designers of the language support system chose to provide a kernel-safe implementation of the feature, you can use it, but not otherwise. The same applies to any language, including C.

          Kernel code, by its nature, often needs to directly access hardware and/or exact memory locations. The kind of languages that are designed to hold the programmers hand and hide such hardware features tend to make that difficult, and have to provide "special" features to bypass their inherent protections. Those can also create problems when used incorrectly.

          1. Doctor Syntax Silver badge

            Re: I was about to

            Just trying to remember why K & R invented C... Oh, yes - amongst other things, to write an OS kernel.

        2. ST Silver badge
          Facepalm

          Re: I was about to

          > [ ...] while good C code is possible, it’s rare and far too many trivial tasks are managed manually and repetitively when coding C.

          Is that why the proprietary UNIX kernels, the Linux kernel, the *BSD kernels, Mach/NeXTSTEP/iOS are all written[*] in C?

          I think even Redmond's Blob is written in C.

          I look forward to testing your new, modern kernel written in Python and Rust.

          -----

          [*] Yes, with some assembler for certain CPU/ISA specific things that can't be written in C.

        3. Anonymous Coward
          Anonymous Coward

          @CheesyTheClown - Re: I was about to

          It's an OS kernel, mate. You don't have the luxury to fumble around with new and exotic programming paradigms. At least not yet.

          1. SGJ

            Re: @CheesyTheClown - I was about to

            We've known about the problems caused by buffer overflows for at least 50 years and yet a simple search of the CVE list for "buffer overflow" returns over 11,000 hits out of a total of 150,000 CVE records. Programming paradigms to reduce or eliminate this basic problem are neither "new" or "exotic" and have well researched - it's about time we started using them.

        4. Mobster

          Re: I was about to

          Maybe Rust can eventually grow up and take the place of C ...

      3. Blackjack Silver badge

        [There were random sleeps added to "fix" race conditions,]

        Now out of context that sounds a bit racist.

      4. bombastic bob Silver badge
        Devil

        Someone will be along in a moment to blame C for all that, by the way.

        predictably so, yeah. And it happened. I'm avoiding that part of the thread.

  2. Version 1.0 Silver badge

    Hardware engineers vs Software Engineers

    Netgate recently "updated" pfSense only to cause a lot of problems, I've used both pfSense and Netgate hardware for a great many years - as independent engineers they were both good, but once Netgate started writing software everything started to slide downhill. To quote a friend of mine from 40 years ago who used to design boards for PDP-11's; "One software writer thinks he can keep a dozen engineers busy but in fact one hardware engineer keeps 20 programmers busy."

    1. Youngone Silver badge

      Re: Hardware engineers vs Software Engineers

      I have pfSense routers and keep wondering if I ought to be moving them to opnSense.

      I have been aware of all sorts of bad blood between Netgate and various people but have never really cared enough to take a side.

      Are Netgate the bad guys here? Does it really matter? I don't know.

      1. Version 1.0 Silver badge

        Re: Hardware engineers vs Software Engineers

        Netgate aren't "bad guys" ... they are simply not people who should be in charge of firewall software. Their hardware has been very good over many years - it's their "hardware" view of life applied to software that's the trouble.

        Look at it this way, if you were going to write firewall software, what language would you chose? C, C++, Visual Basic, Java, or Python? What's more important - the ease of writing the code, or the security of the code?

      2. Mark 65 Silver badge

        Re: Hardware engineers vs Software Engineers

        Netgate's director of engineering, Scott Long, who said: "My team and I were proud of the work, proud of the results, and eager to share it with the pfSense and FreeBSD communities.

        This tells me more about Netgate than they likely want me to know. They make firewall appliances FFS and yet they feel ok with writing software full of vulnerabilities and noob workarounds?

        I'm starting to wonder whether I should remain using my pfsense appliance, especially given the latest release has an issue with unbound crashing / becoming unresponsive. Since it moved to pfsense+ (21.02) from 2.4.n I've have noticed things seem to have slowed a bit, especially around the initial site contact.

  3. Anonymous Coward
    Anonymous Coward

    Check out NetBSD mailing lists about NB wireguard. Same kind of story, but NetBSD maintained they had a quality implementation.

    http://mail-index.netbsd.org/tech-net/2020/08/22/msg007842.html

    As an outsider I got the strong feeling that the only issue was that Donenfeld was not involved in the port. He hinted about many issues, but did not seem.to give a single concrete example.

    No idea what happened about the meeting the participants agreed upon.

    1. This post has been deleted by its author

    2. Anonymous Coward
      Anonymous Coward

      @AC - You missed the part where

      [quote] Donenfeld got together with core FreeBSD developer Kyle Evans along with Matt Dunwoodie, who had worked on a WireGuard implementation for OpenBSD. [/quote]

      That's quite a team to me and it seems Donenfeld was able to convince the two so your strong feeling is just a speculation.

      1. aebiv

        Re: @AC - You missed the part where

        And you can see Kyle isn't such a fan of how Jason handled things either, and called out a lot of his claims as baseless.

        I think there were obviously issues with the code, but when isn't there?

        But I also think Jason really just likes drama, and dropping in last minute. After all, this code has been lives for 4+ months, and it's only during the countdown does he magically pop up to make a big scene.

        The dude may be a savant when it comes to programming, but I certainly don't care for how he handles things (and no, I'm not a fan of the way Netgate often does either.)

  4. Missing Semicolon Silver badge
    Boffin

    Why is Wireguard in the kernel?

    It seems to me that a complex protocol like a VPN is always going to be subject to vulnerabilities due to coding errors. Even the bestest of coding magicians will make a mistake somewhere. So running this stuff at Ring0 seems only slightly less dangerous than, say a web server. Both are processing data from the wild west internet.

    Would we not sleep a little better if it ran as a module in it's own security context?

    1. bombastic bob Silver badge
      Devil

      Re: Why is Wireguard in the kernel?

      It's probably contributed code

      You _could_ write a kernel module as a port. I've done it (more than once). Then someone who wants the kernel module can install it from FreeBSD ports, or maybe just copy the port files onto the target machine and build it. All you need is kernel headers and the ports collection to do that.

      But inclusion as part of the base system requires that it meet some specific standards, from coding style and naming of variables to reliability and security.

      Usually it gets a lot of peer review. At least, that's been my experience in the small number of contributions I've made.

      (if you have something good to contribute, it's worth going through the process, spend some IRC time with the core devs, submit it to Phabricator for review, have specific people review it, and so on)

    2. Charlie Clark Silver badge

      Re: Why is Wireguard in the kernel?

      Why wouldn't you want it with the rest of the networking code? It's a module, so you can easily remove it. But I'm not sure security is as much of a problem here than reliability which you want above almost everything in the kernel to stop errors bringing the whole thing down.

      And, given that this is not a "new" thing, which you probably wouldn't want in the kernel until all the tyres have had a proper kicking, this is really more about the process: getting other developers in earlier before the code drop would have prevented a lot of problems happening and is one of the main benefits of open source development.

      And don't forget the risks attendant with all those binary drivers that hardware manufacturers continue to drop.

      1. Crypto Monad

        Re: Why is Wireguard in the kernel?

        The cool kids are doing networking in userland anyway. See for example VPP/DPDK, commercialised as TNSR (coincidentally also by Netgate)

  5. nautica Bronze badge
    Happy

    "Originality is no excuse for stupidity"--Fred Brooks

    "Most software today is very much like an Egyptian pyramid with millions of bricks piled on top of each other,‭ ‬with no structural integrity,‭ ‬but just done by brute force and thousands of slaves.‭"---Alan Kay‭

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

Biting the hand that feeds IT © 1998–2021