|Microsoft Open Sources Checked C
|Written by Mike James
|Wednesday, 15 June 2016
Checked C is an extension to the C language aimed at making is more secure and reliable. Can this reduce the occurrence of vulnerabilities in so much system software?
C is still an important language. It is used both in high level systems software like operating systems and low level code used in embedded processors. The reason it is still a good choice in that it is close to the hardware and efficient. Of course, any application that doesn't need to be close to the hardware is better coded in a more modern and more abstract language that protects you from the sort of errors that can occur in C - as long as you can accept the potentially lower efficiency.
The main problems that arise in using C all stem from its raw pointer facilities. In C a pointer is a thinly disguised machine address, and as such you can use it to access any memory location. This is usually the reason for using C, but often this goes horribly wrong when the data that is being stored is more than the allocated memory can hold. This situation gives rise to the dreaded buffer overrun, which can result in the program crashing, the system crashing or the machine being taken over by an attacker.
The problem is that the C language doesn't check to see if you are using a pointer within the memory region you intended to use it. Checked C, as its name suggests, checks that you are within the stated memory area.
Checked C is an extension to C so your existing programs will still work, but of course you don't get anything new if you don't make use of the new pointer types.
There are three different checked pointer types:
The first is a simple pointer that doesn't support pointer arithmetic - it just points at a location and it is checked to make sure it isn't null before use:
Most buffer overrun type errors occur when pointer arithmetic is used to move a pointer on but many pointers are used in this way - so it is better to make them safe and explicitly remove them from the possibility of pointer arithmetic.
The second is a pointer to an array of known size:
This is checked to make sure it is within the declared array bounds as it is used. This means there is no chance of accidentally reading or writing beyond the end of an array.
The third is a generalization of the second to and arbitrary area of memory of varying size:
The bounds of the area are carried with the pointer and adjusted dynamically. The pointer is checked for being in the bounds and non null every time it is used.
In addition there are checked array types that match the checked array pointer:
So if you try and use a the result is a runtime error.
Is this all a good idea?
It is such a good idea that it is very difficult to see why it hasn't been introduced to C before. The argument is often made that the reason C hasn't had checked pointers before is that checking takes time and it is up to the programmer to decide to include a bounds check or not. Of course, if you extend C to include pointers with bounds checking then the programmer can decide to use or not use depending on the situation.
The is another question - do we really need improvements of this sort in languages?
IDEs such as NetBeans do a lot of analysis of your code and will flag potential problems. NetBeans will flag a much wider range of problems than just pointer difficulties - including things like relying on the zero termination of strings in library functions rather than using safer alternatives.
Of course, there are lots of programmers who refuse the help of an IDE and prefer to work with minimal tools. Compilers such as GCC and CLANG don't really go out of their way to be IDE friendly, which is decidedly an old fashioned approach. Compare this to the attitude of the Microsoft C# team which holds the view that compilers should target tooling not machine code - see Anders Hejlsberg - Compiler Construction The Modern Way.
Modifying C is not a terrible way to go but making the tooling better and actually using it is another and it is potentially much more rewarding.
or email your comment to: email@example.com
|Last Updated ( Wednesday, 15 June 2016 )