This is the first video of the Course 7. This course is about driver development. This course also cover the kernel module development and more precisely, the device driver development that is a king of kernel module. It only talk about Linux kernel module, but the general concept also apply to Windows device driver. It's really just an introduction to the safe way to develop device driver on Linux. Developing device driver in Linux or on Windows is a complete subject by itself and it could be covered by a very separate learning path than this one. But I just want to include in this learning path the very important aspect for the security, just because the C and C++ is used to create the kernel module and the device driver. What is a kernel module? Very good question. Kernel module is an object file to be load as part of the Linux kernel. [inaudible] object that we load as part of the process but for the kernel. The code in kernel module run as part of the kernel. We say it run in kernel mode. Unlike application run in user mode, code running in kernel mode are not restrained by the kernel. Our code running in the kernel mode can access and control hardware device, can access any memory no matter which process on it, it can control any process, say kill process, create process in any way, and can access any file. Some Linux user or Windows users say that kernel run as root and there's some teacher also see it like this. This is not really true. The kernel is the one who decide what root or other user can do or cannot do. This is not the root user. This is what give the root user the privilege they have. What is a device driver? A device driver control the device. The name is clearly indicating that it can be a real hardware device or a simulated device. We could create a device driver for run disk, for example. Device driver can also be used to implement a protocol or a network protocol or other kind of protocol. If we talk about real device driver, we can think about a network adapter device driver, SATA controller device driver, SATA disk device driver and other hardware that are connected to a computer. If we talk about device driver, that does not control device but rather implement a protocol. We can think about file system driver or network protocol driver. We could have a device driver that implement the TCP/IP protocol. We could also have a device driver that implement the file system or other file system. Application interact with the driver or in an implicit way or an explicit way. When we talk about implicit interaction is because the application will interact with the device driver but through a specific subsystem. For example, the notification does not interact directly with the driver for the network adapter. It will use the network subsystem to create circuit and exchange information over the network. It will clearly, by the way, use the network adapter driver but without knowing it used it. Same thing with the notification to save a file on the disk, they will use the device driver for the disk but will not directly use it, it will use it through the file system. But in some cases, the application will directly interact with the device driver. Example, an application can open the driver for a serial port and use it to communicate with some hardware. As we saw in the previous course, an application can open the random generator driver and read random generator number from it. It clearly, directly interact with this, a special driver that is a driver for a virtual device and not a real device in this case. When an application interact with a device driver, the operating system manage permission to allow or not an application to connect with the device driver. But once the connection is established and allowed by the permission, the device driver is the last line of defense of the operating system. Once the connection is established, the application can send all kind of operation request to the driver and the driver is the one that will accept or not to execute the requested operation. If the driver does not validate command or data it receives, it will compromise the security of the whole system. In the previous slide, I said that the operating system is responsible for verifying if an application have the permission to connect with a device driver. On Linux, they do that using the node in the /dev directory. Each node have some permission and this permission is used to know if application or rather if a user can use the device, can talk with the device directly. On Linux, they have a special services called udev that manages the node in the /dev directory. This is the services that will sometime create the node and also set the permission on the node it create. The programmer of the device driver must ensure the permission is correctly set at installation time, so it would provide a package to install the device driver or configure with the udev services or create the node in other way and configure the permission in the node directly if they don't want to use the udev services. This is clearly outside the scope of the course named Secure C and C++, but I just wanted to make a note on this. This course contain four other video. The next one is about their kernel stack. The other one about read, write and IoCtl operation and their interface, how the operating system call the device driver. The fourth video is about error handling in the case of a device driver or a kernel module. The last video is of some note about the Windows. This is the end of this introduction video, the next video is about kernel stack.
