Re: I'm done with Windows.
Ohhh... I'm glad I came back here.
C is a great language and it's extremely diverse. It's absolutely horrifying for something like the Linux kernel though. Consider this, it has no meaningful standard set of libraries which means that support for things like collections and passing collections is a nightmare. Sure you have things like rbtree.[hc] in the kernel, but as anyone who has studied algorithms knows, there is no single algorithm which suites everything.
Let's talk about bounds, stacks, etc... there's absolutely no reason you can't enhance the C compiler to support more memory protection as well. C itself is a very primitive language and it's great for writing the boot code and code which does not need to alter data structures. But there are severe shortcomings in C. Yes, it's 100% possible to add millions of additional lines of repetitive and uninteresting code to implement all those protection checks. But a simple language extension could do a lot more.
Let's talk about where I find nearly all of the exploits in the kernel. This is in error handling and return values. It's amazing how you can cause problems with most code written at two different times by the same person or by two different people. The reason for this is that there's no meaningful way to handle error complex error conditions. Almost all code depends on just returning a negative value which is supposed to mean everything. The solution to this is to return a data structure which is basically a stack of results and error information and then handle it properly. The reason this isn't done is because people get really upset when implementing anything resembling exceptions in C. And yet, nearly every exploit I've found wouldn't have been there if someone implemented try/catch/finally.
Let's talk about data structure leaking and cleanup related to the above. Better yet, let's not... pretty sure that one sentence was enough to cover it all.
This is 2017, not 1969. In 2017, we have language development tools and technologies that allow us to make compilers in a day. This isn't K&R sitting around inventing the table based lexical analyzer. Sticking with the C language instead of creating a proper compiler designed specifically for the implementation of the Linux kernel is just plain stupid.
More importantly, there's absolutely no reason you have to use a standardized programming language for writing anything anymore. If your code... for example an operating system kernel would profit from writing a new programming language for it... do it. You can base it on anything you want. It's actually quite easy... unless you write the language itself in C. Use a language suited for language development instead. Get the point yet?
The next big operating system to follow the Linux kernel will be the operating system which leaves 95% of the C language in tact and implements a compiler which :
a) Eliminates remaining dependencies on assembler by implementing a contextual mode for fixed memory position development.
b) Provides a standard implementation of data structures as the foundation of the language
c) Implements a standard method of handling complex returns... or exceptions (possibly <result,errorstack>)
d) Implements safe vs. non-safe modes of coding. 90% of the Linux kernel could easily have been done in safe mode
e) Offers references instead of pointers as an option. This is REALLY important. Probably the greatest weakness of C for security is the fixed memory location bits. Relocatable memory is really really useful.If you read the kernel and see how many ugly hacks have been made because of it not being present, you'd be shocked. The Linux kernel is completely slammed full of shit code for handling out of memory conditions which exist purely because of supporting architectures lacking MMUs. References can be implemented in C using A LOT of bad and generally inconsistent code. It can be added to a compiler with a bit of work, but when combined with the kernel code, can implement a memory defragmenter that could fix A LOT of the kernel.