5 ms·
Why is kernel programming any different from user-level programming here? I tend to think that the driver and network level, which is where most problems in th
by pcwalton 9y ago
Why is kernel programming any different from user-level programming here?
I tend to think that the driver and network level, which is where most problems in the real world tend to lie, is similar to userland in how often unsafe code gets used and the impact of unsafe code on the correctness of the kernel. In fact, the fact that you can write some drivers in userland on certain OS's--and they can crash without bringing down the whole OS--is strong evidence of this.
- zaarn 9y agox86 is unsafe. Period. A lot of devices are unsafe. Period. You can write some device drivers in userspace. But you can't handle page faults in userspace. Those need to be handled by the kernel and will be 100% unsafe because any mistake will lead to a certain and quick double or triple fault. Kernel Level Programming is very very different to normal user-level programming. There is no malloc. There is no segmentation. Nothing prevents you from dereferencing a null pointer. In fact, in kernel-land a null pointer is valid memory. You don't have any of the forgiving properties of Ring3 assembly code in kernel-land.
- rcxdude 9y agoWhat you are describing is <10% of, say, the linux kernel. The rest of it reads very much like user-land code (and dereferencing a null pointer will often earn you a nice warning message if not a panic).
- zaarn 9y agoThose are usually the important 10% of a kernel that build the foundation of everything else. Once you have VMM and Paging setup, preventing a null pointer deref is not hard (simply unpage 0x0)