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.
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.
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.
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.