Talking to devices

Most embedded systems will have some sort of specialized device that they are talking to, to perform the main system task - may this be a data-acquisition card or a stepper motor controller. These 'custom devices' are a crucial point in the embedded Linux area, as these will rarely rely on widely deployed drivers and have a limited test-budget available. So to ensure the overall system security, a few simple rules need to be kept in mind when designing such drivers. Regular linux device drivers operate in kernel space. They add functionality to the Linux kernel either as builtin drivers or as kernel modules - in either case there is no protection between your driver and the rest of the Linux kernel. In fact kernel modules are not really distinct entities once they are loaded, as they behave no differently than built-in driver-functions, the only difference being the initialization at runtime. This makes it clear why device drivers are security relevant: a badly designed kernel module can degrade system performance all the way down to a rock-solid lock-up of the system. A really badly designed driver will not even give you a hint at what it was up to when it crashed. So drivers, especially custom drivers, must aim at being as transparent as possible. To achieve this, a flexible system logging should be anticipated. This may be done via standard syslog features as well as via the /proc interface and ioctl functions to query status of devices. The later also can be used to turn on debugging output during operations, a capability that, if well designed, can reduce trouble-shooting to a single email or phone call. Aside from these logging and debugging capabilities, a driver design must take into account that there is no direct boundary between the driver and the rest of the kernel. That means the driver must do sanity checks on any commands it receives and in some cases on the data it is processing. These checks not only need to cover values/order and type of arguments passed, but also check on who is issueing these commands - the simple read-write-execute for user-group-other mechanism of file permissions is rarely enough for this task. RTLinux devices are not that much different from regular linux devices with respect to security considerations, but they differ enough that this difference should be mentioned explicitly. Noting this for RTLinux only is only due to the fact that my work covers this RTOS variant of Linux, but basically it should hold true for the other flavours of realtime Linux variants (corrections appreciated).

A simple example of setting up a secure RTLinux device would be a motor controller kernel module. This module must be loaded by a privileged user (the root user) and needs to be controlled during operation. To achieve this:

• Load the module and system boot via init script or inittab.
• change the permissions of a comand FIFO (dev/rtfN) to allow a non-privileged user to access it.
• send a start/stop/controll command via this FIFO as the unprivileged user.
• check the validity of the command and its arguments.
• log such events with timestamps and user/connection related information to the systems log facility.
• monitor the logged events and follow development of driver parameters during operation.
• document the system behavior in a way that deviation can be located in debug and log output.

If a scheme of this type is followed, then operating a system with custom devices will exhibit a fair level of security. Clearly, a non-standard device will also require an increased amount of documentation and instructions for the operator, as the behavior of non-standard devices can hardly be expected to be well-known even to knoledgable administrators.