Microsoft Releases Checked C

[kpedersen]

Finally, a project I am actually interested in from a large software company since Sun Microsystems disappeared!

http://www.theregister.co.uk/2016/0...en_source_bugbomb_in_the_rambling_house_of_c/

http://research.microsoft.com/en-us/projects/checkedc/default.aspx

I was attempting to achieve the same goal with one of my projects, libstent (https://github.com/osen/stent) which utilizes a bunch of MACRO hacks to create something like std::weak_ptr<T>. However, something built into the language is much better.

It also means that I have another reference for my paper that C is still relevant and infact, critical!

Microsoft Research is actually quite interesting in general. Some random trivia. The first version of the .NET framework and C# ever developed by MSR actually supported FreeBSD (4.7) .

https://www.microsoft.com/en-us/download/details.aspx?id=14124

You can build a couple of tools (like nmake) but too much has changed to get it fully working on CURRENT.

 

[tomxor]

Some random trivia. The first version of the .NET framework and C# ever developed by MSR actually supported FreeBSD (4.7) .

That kinda makes sense, back in the day they were using FreeBSD for things like hotmail before their server OS was mature enough.

Microsoft Research is actually quite interesting in general.

Most research departments seem like nice places even as someone who treats Microsoft as the devil incarnate I can see how good things could come out of their research. Remember Bell Labs? fostering amazing ideas and people like Claude Shannon... and yet it's all under that giant AT&T...

 

[tomxor]

Microsoft notes that between 2010 and 2015, buffer overflows were behind as many as 16 per cent of the bugs added to the US National Vulnerability Database each year. The specification document lists the Windows and Linux operating systems, IE, Chrome and Safari browsers, Apache, OpenSSL, Bash, Ruby and PHP scripting languages and QuickTime as all suffering from buffer overflows in that period.

I'm not a proper C programmer but at least I can appreciate the statistics makes sense to put effort into a solution addressing the largest single factor that causes bugs and vulnerabilities

 

[kpa]

Something like this is very welcome but it won't be adopted by the open source community as a standard very easily because of the Stallmanites.

 

[drhowarddrfine]

The buffer overflow problem is what we call a "bug" which we test for and fix. It's part of the job of using the language. Otherwise we might as well use some other higher level language.

 

[kpedersen]

The buffer overflow problem is what we call a "bug" which we test for and fix. It's part of the job of using the language. Otherwise we might as well use some other higher level language.

I agree to an extent but sometimes you really don't need (or want) a higher level language but you also want a way to guarantee memory safety.

For a few of my projects, I use C++ rather than C purely because of std::weak_ptr<T> when dealing with complex data structures. However this is a shame because it drags in C++ problems such as STL, unportability, unstable ABI etc...
If I can keep using C but just fix the memory safety issue, I think that could be an acceptable compromise.

Even better since Unchecked C and C are compatible. This means that Unchecked C can be used like a development tool similar to Valgrind and then the code can be released using standard ANSI C.

 

[tomxor]

The buffer overflow problem is what we call a "bug" which we test for and fix. It's part of the job of using the language. Otherwise we might as well use some other higher level language.

It is a bug and ultimately you can say the programmer is to blame, but it sounds like your treating a language like some kind of ultimate truth.

If it's a common mistake yet intrinsic to the language and level of abstraction, doesn't it make sense to build in some automatic analysis of those areas?

That's not the same as using a higher level language, that's just making the degree of separation from the creator and the creation smaller so that a better understanding can be had and less bugs made.

 

[drhowarddrfine]

If using a higher level language separates the programmer from the creation then you lose the advantages of C so, yes, the language is the ultimate truth with the reason for using C in the first place.

 

[tomxor]

Then why don't you only use assembly, or binary? What's with the seemingly arbitrary level of "truth"?

Sorry slightly rhetoric... I don't really want to language war, my point really is that this looks like a way of analysing or debugging aspects C, to me that !== making it C++

 

[kpedersen]

To be honest, I just find it refreshing that their solution to preventing memory errors isn't simply developing a new gimmicky language with no real native library support. Instead they are finally seeing value in extending the C language rather than trying to replace it.

If I have a C library I need to use, I cannot really use C++ because I would need to wrap it in classes to see any benefit to memory management, I certainly cannot use a high level language like Java or .NET because I would have to spend a month writing bindings before I even start. I would probably just have stuck with C and be very careful and keep a Linux box around for Valgrind (still a bit dodgy on FreeBSD). However with Checked C, I am hoping that I could start development straight away in a safe manner.

 

[Maelstorm]

<sarcasm>

The way that I see this is if you don't want bugs in your software, then don't put them in there in the first place.

</sarcasm>

Seriously though, any time that I use a buffer, I always have a size attached with it so I can check to make sure it hasn't been overflowed. The buffer overflow attack, although it can be done with the heap, is more of a stack based attack because then you can directly change the return address on the stack. That's not so easy to do with the heap. So the number one issue that I see is that people are allocating buffers into the stack that should be allocated on the heap instead. That one change alone will significantly reduce the risk of buffer overflow attacks. The second part of my solution is to attach a size to every buffer, and check it when reading/writing that buffer. But hey, this is what I do, and I have yet to have any problems with my code.

 

[drhowarddrfine]

Maelstorm Exactly

 

[fossette]

The buffer overflow problem is what we call a "bug" which we test for and fix. It's part of the job of using the language. Otherwise we might as well use some other higher level language.

I agree to an extent but sometimes you really don't need (or want) a higher level language but you also want a way to guarantee memory safety.

I'm more with kpedersen on that one. However, the added features of Checked C are not very transparent. In general, I would prefer added safeguards against buffer overflow built into the C compiler itself. For example, the -bbc or --BufferBoundaryCheck compilation option (or would that be too confusing with other acronyms...). Maybe I'll draft an RFC someday...

Dominique.

 

[fnj]

The buffer overflow problem is what we call a "bug" which we test for and fix. It's part of the job of using the language. Otherwise we might as well use some other higher level language.

In the case of gets, the bug is in the API design. gets is just broken by design, and pointlessly so. The new gets_s is an effective fix which is trivial to implement. The other *_s additions, such as strcpy_s, strcat_s, etc, are a little less clear-cut, because we already have strncpy, strncat, etc, which if unwieldy do at least make it feasible to avoid overflows by careful coding. However, in the end, I simply cannot fathom why closed minds (e.g., gcc) are obstructing what should have been an overnight adoption of checked C some 5 years ago.

 

[kpedersen]

I am actually in the process of writing a paper of my own in the same field using some of the safety systems in libstent.

I decided to develop it further because I am writing 99% of code for my PhD in C since Plan 9 has no C++ compiler (I tried the re-port of Cfront for the 4th edition but it was extremely limited as far as C++ compilers go and never really had exception support).

libstent now supports:

- Guarantee of no dangling pointer errors
- Array bound safety
- A form of RAII (very similar to std::auto_ptr<T> / std::tr1::weak_ptr<T>)
- Exceptions
- Memory cleanup in exceptions (longjmp behind the scenes)
- A form of std::tr1::dynamic_pointer_cast<T>.

In it's simplest form...

ref(Employee) emp = {0};
ref(Employee) emp2 = {0};

emp = EmployeeCreate();
emp2 = emp;
EmployeeDestroy(emp); // Not needed if using built in RAII

get(emp2)->age = 7; // Throws exception rather than undefined behaviour

I wrote a fairly straight forward student attendance system for the University I am working for and decided to use libstent. I was pleasantly surprised when valgrind reported completely free from leaks and errors! Maybe you guys might want to check it out? (github link in first post).