Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror
Microsoft Open Source Programming Java Operating Systems Privacy Security Software Windows News Build Technology

Microsoft Open-Sources 'Checked C,' A Safer C Version (softpedia.com) 208

An anonymous reader writes from a report via Softpedia: Microsoft has open-sourced Checked C, an extension to the C programming language that brings new features to address a series of security-related issues. As its name hints, Checked C will add checking to C, and more specifically pointer bounds checking. The company hopes to curb the high-number of security bugs such as buffer overruns, out-of-bounds memory accesses, and incorrect type casts, all which would be easier to catch in Checked C. Despite tangible benefits to security, the problem of porting code to Checked C still exists, just like it did when C# or Rust came out, both C alternatives.
This discussion has been archived. No new comments can be posted.

Microsoft Open-Sources 'Checked C,' A Safer C Version

Comments Filter:
  • by God of Lemmings ( 455435 ) on Thursday June 16, 2016 @09:05PM (#52333189)
    I seem to recall long long ago someone else made a C compiler that did this.
    • Some old GCC? (Score:4, Informative)

      by snikulin ( 889460 ) on Thursday June 16, 2016 @09:15PM (#52333249)

      Long long time ago (~2000?) I used GCC's bounds checking feature.
      If I recall correctly, I had to compile my own GCC because it was the only way to enable it.

    • There was an effort at Cornell University to produce 'Cyclone'. It required a modifications to gcc.

      If MS made this a 1st class citizen of Visual Studio it might gain some traction. That it's using LLVM sounds intriguing - might MS be switching to the platform for its compiler suite?

      • These changes are, indeed, very similar to Cyclone. The main difference is that they're not an all or nothing approach. You can still do unsafe things in Checked C, you will just be able to audit your code to see where you do them and gradually apply them. The lack of an incremental adoption path was probably what killed Cyclone.

        As to Microsoft using LLVM, current versions of Visual Studio support all four combinations of the MS and Clang front ends and the MS and LLVM back ends. I don't think that the

  • by MrKaos ( 858439 ) on Thursday June 16, 2016 @09:11PM (#52333233) Journal

    #include telemetry.h

    • by wierd_w ( 1375923 ) on Thursday June 16, 2016 @09:17PM (#52333269)

      no no no.

      MS wouldnt put telemetry as a header. You can choose not to include, or worse, edit, header files.

      no no. The CC will hard link "telemetry.o" to every project at compile time, and wont have any switches to disable that behavior. Don't worry, they use digital signature checking to be sure that telemetry.o is the object file it expects it to be. Cant have untrusted objects in the linking phase now.

  • by Yvan256 ( 722131 ) on Thursday June 16, 2016 @09:16PM (#52333255) Homepage Journal

    That's it, I've had enough. I'm going back to Turbo Pascal.

  • I'm confused - is Microsoft reinventing C++ or reinventing Java? I can't tell which decade from the last millennium they're trying to drag us back to. (Maybe as far back as when they were considered a reputable software company?)

  • by GrahamCox ( 741991 ) on Thursday June 16, 2016 @10:37PM (#52333595) Homepage
    The CPU just needs to set aside an area of memory exclusively for return addresses, and make that protected. No more security issues, buffer overruns, execution of arbitrary code. The real problem is that return addresses are mingled with other data. This should be solved at the hardware level, and AFAICS, it could be done totally transparently to code, even binaries.
    • by sdw ( 6809 ) <[sdw] [at] [lig.net]> on Friday June 17, 2016 @12:39AM (#52333855) Homepage

      That's the right direction. Apple already has a pretty good version of it. (See below.)

      Bounds checking C like this now is weak and very, very late:
      https://gcc.gnu.org/ml/gcc/199... [gnu.org]
      https://www.lrde.epita.fr/~aki... [epita.fr]
      http://blog.qt.io/blog/2013/04... [blog.qt.io]
      http://valgrind.org/docs/manua... [valgrind.org]
      https://en.wikipedia.org/wiki/... [wikipedia.org]

      But the grand champion memory debugger is the Mac OS X standard malloc libraries. You can simply set environment variables and instantly get better debugging than most methods on all other platforms. I presume this is because Objective C/C++ is such a pain to debug that they just built in features to always be available, even for production apps.

      http://www.cocoawithlove.com/2... [cocoawithlove.com]

      Those libraries are clever because when debugging array bounds corruption and used/free, all mallocs get their own mmapped memory block surrounded by unmapped memory. Plus writing patterns into free / allocated memory to detect writing to freed memory, etc. This is great because it triggers a system signal that debuggers can catch deterministically.

      I found and used those techniques on my last big project a couple years ago. The Windows desktop app and imaging C++ libraries were full of errors, memory corruption, struct and 32bit/64bit problems, etc. I had to do a lot of debugging and rewriting to port to Mac OS X, then a lot to solve corruption and threading issues. And found out, the hard way, what a mess the "standard" pthreads API / libraries were. Just spurred me on to switch to C++11 to have standard threads. This Mac OS X built-in debugging along with gdb made it a snap to find all of those kinds of errors, even for code meant for Android, Linux, and Windows.

      • What's wrong with the standard pthreads API?
  • by Uecker ( 1842596 ) on Thursday June 16, 2016 @11:36PM (#52333747)

    The funny little known fact is: C99 already has a bounded pointer type: A pointer to a variable-length array.

        void foo(int N, char (*ptr)[N])
        {
            (*ptr)[N + 3] = 10; // undefined behaviour
        }

    Using the undefined-behaviour sanitizer, you can also have the compiler add automatic checks.

  • So checked C is simila to Pascal?

  • It is absolutely astonishing that it has taken _this_long_ for someone to make these basic fixes to C.

    • It's more surprising that people think C needs "fixing". C is just a toolbox with almost no restrictions - so you have to be careful using it. Once you start adding restrictions to your tools, you end up with other problems.

      Put another way, C is almost the ultimate in coding freedom (probably only assembler is more free, but is not quite as portable as C) so requires lots of responsibility. Adding in checks to a language does free the programmer from responsibility but necessarily comes at the cost of som

  • I wonder if some kind of AI (Watson or similar) is going to deprecate a lot of these programming languages, extensions, and tools. Imagine if your AI could analyze your millions of lines of code in a few minutes, then aggressively optimize it and patch all of the bugs and vulnerabilities, while still giving the same intended output 100% of the time. I wonder what programming would look like at that point.

    I imagine at that point everybody would be using a programming language like Go or Python that emphas
  • by sproketboy ( 608031 ) on Friday June 17, 2016 @08:44AM (#52335421)

    Another indication that M$ recognizes that .NET and C# have failed.

  • Telemetry calls embedded via the compiler? Check!
  • And, so, how is this different from lint?

    For that matter, none of all the C I used to write ever had buffer overflows, or memory out of bounds, etc. Of course, I wasn't right out of school when I wrote it, nor was I lazy... so, for example, I almost *never* used while/wend - overwhelmingly, it was for/next, with *LIMITS*. After some early C programming bugs that I fixed, I started, more and more, using strncpy.. And I *checked* the return from malloc.

Moneyliness is next to Godliness. -- Andries van Dam

Working...