Slashdot Mirror
Microsoft Open-Sources 'Checked C,' A Safer C Version (softpedia.com)
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.
strcpy_s is part of the C11 standard, and it was a library addition, not a language change.
This won't gain traction until it's compatible with the C99 and C11 standards.
how the heck are you gonna shoehorn this into standard C? We are talking about restricting what the programmer can do, there's NO WAY you can achieve bounds checking behavior without breaking existing C behavior, because "broken" programs with bounds checking problems are "perfectly acceptable" C.
My ism, it's full of beliefs.
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.
That's it, I've had enough. I'm going back to Turbo Pascal.
It baffles me the sheer number of warnings some projects generate on compilation. Sure many aren't relevant, but some are, and if your code generates bucketloads the chances of missing the important ones is high. And really: how hard is it to do simple things like putting extra braces around if statements where you really do want to do an assignment, properly casting things (signed -> unsigned for example), or typing (void) foo; when you really want to include argument foo in the function arguments even though it isn't used... yet. Personally I don't consider my code complete until it compiles with no warnings under -Wall at least.
That said... I think people need to accept that C just is what it is, quirks and all. If you want strong type checking etc then there are plenty of alternatives to choose from.
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.
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]) // undefined behaviour
{
(*ptr)[N + 3] = 10;
}
Using the undefined-behaviour sanitizer, you can also have the compiler add automatic checks.
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...
https://www.lrde.epita.fr/~aki...
http://blog.qt.io/blog/2013/04...
http://valgrind.org/docs/manua...
https://en.wikipedia.org/wiki/...
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...
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.
Stephen D. Williams
As yet, nobody has made an OS that isn't C at the bottom. There's a reason for that. Although there are projects that claim it's now possible, not one major operating system uses them for kernel programming.
And wrappers like this have existed since the first day of C. You can always wrap your own memory and pointer management functions and structures and just expect people to use them. They come with a performance cost, and wrapping C means people can only use your wrappers. Even this, which claims compatibility, basically just introduces two new pointer "types" which can't be dereferenced in the normal way.
It's not that this has been impossible forever and people are only just going "Oh, maybe we should do something". It's been this way because there are things that you need to take account of still. And though security is certainly a high-priority, a system that runs dog-slow, isn't compatible with other APIs, has to have tricks all over it to make it work, and ultimately still has to end up with hardware pointers where the bounds are set by the programmer (as here) means that it won't get used at all.
There's a reason that even "theoretical" OS like MINIX still use C and pointers. At the OS level, hardware access needs unbounded pointers or pointers that only the programmer knows the bounds of. Basically, bang, security problem if they use them wrong.
Even ordinary applications made in pointer-managed languages have to - by definition - include more checks and code than those that don't. I'm not saying those checks aren't worthwhile, or don't stop security problems, but there is still yet to be a serious OS or even low-level drivers written in anything other than C.
And people speak as if, if we were to all just move to Rust or whatever (which also includes its own pointer types including a special insecure "unbounded" pointer - wonder why that is even in there, hmm?) that all the security problems would magically disappear. Unfortunately it's not like that.
It's about eliminating human error and there's a lot that can go wrong with pointer arithmetic and lack of checks. But that human error is present whether or not a pointer is used. Most of the time the problem is lack of bounds checking - that, in any language, can lead to serious problems like crashes, acting on incorrect data, getting into infinite loops, etc.
The problem is that the one part you NEED that kind of balance, deep in the kernel rings where you're using drivers and low-level memory access outside of the normal protections, you don't have it available as the hardware needs real pointers to be manipulated in order to operate.
Pretty sure a lot of operating systems used Assembler at the bottom in the early 2000s. Now, I think they're pretty flexible, like:
https://github.com/CosmosOS/Co...
Change is certain; progress is not obligatory.
And sometimes, the weird behavior is actually the right behavior - even when compilers disagree. Remember the issue a few years ago when it turns out almost all the sshkeys generated on any debian (or debian-derived) system were highly predictable ? It happened because the random-number generator in openssh was throwing a compiler warning for "considered dangerous" handling of a pointer - except that, in that case, it was a critical part of the entropy feed. Some debian packager wrote a patch to "fix" the code to proper bounded behaviour... and ended up castrating the entropy feeder function.
It no longer threw a warning - it just led to one of the worst security problems in Linux history and took weeks to recover from when it was discovered years later and everybody had to regenerate their keys.
Unicode killed the ASCII-art *
As yet, nobody has made an OS that isn't C at the bottom.
What nonsense.
Perhaps you like to google a bit or read wikipedia? Mac OS e.g. was written in Pascal. Other OSes are written in Forth, Java, Oberon, Modula II. There are plenty of OSes you never heard about written in Languages you never heard about.
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
and all of it is C.
That is wrong.
All embedded systems I was involved in the last 10 years used: C++
And still half of all embedded systems build in Avionics use: Ada
For example, the Freescale line of coldfire processors all use a tool called codewarrior.
You clearly have no idea what you are talking about.
Codewarrior is an IDE!!! It uses what ever compiler you put behind it. And usually that is a variation of GCC.
Codewarrior is an IDE that was originally written by Metroworks for MAC OS, an IDE focused solely around C++. The fastes C++ compiler for Macs around that time and later acquired by Freescale.
http://www.nxp.com/products/so...
Scroll down to: "Unlimited C/C++/EC++/cC++ Compiler and Debugger for HCS12(X) derivatives and XGATE module "
C has been ported to every instruction set that has ever been invented, and there are more C compilers in the world than there are Java, C++ and Python compilers / interpreters combined.
How is that relevant to the points I made? (If it is even true)
The IEEE keeps a list of the top languages, and their list includes the embedded space which is ignored by these other lists. C and C++ take the #2 and #3 spots, which accurately reflects the underlying reality. ... not for smart watches, not for iPads, iPhones, Samsung Galaxies or any other Android device.
For embedded programming!!! Yes. Not for business code. Not for web pages
If one hires a developer because he has used Codewarrior and ditches one who used Code Composer Studio instead: he is an idiot.
If I had to hire an embedded programmer I would insist on seeing some C/C++ code and would not care what kind of tools he used.
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.