More uses for an MMU

Some time ago, I wrote about the use of a memory management unit (MMU) for embedded applications and covered the basics of what such a device can do. Recent comment on that posting inspired me to think more about how an MMU may be used more creatively.

The basic function of an MMU is to control a relationship between the addresses that a CPU uses to access specific memory areas and their actual physical address. It can also deny access to specific memory areas entirely. This functionality is controlled by information written to a number of registers in the device. These registers are normally accessed by the operating system so that the view of memory changes, depending on which task is currently running. This is the conventional application of an MMU and is useful, but there are other possibilities …

An MMU is normally associated with process model operating systems [like Linux and Windows, for example]. As each process is scheduled, its area of physical memory is mapped into the logical space beginning at zero. Thus, each task [along with the operating system itself] is protected from unauthorized access by other processes. A thread based operating system – like most embedded OSes – may still use an MMU, but, instead of remapping addresses, it simply uses the device to protect memory areas. I discussed this in a previous blog. It is an option with Nucleus.

There are more creative ways to use an MMU. I wrote about one possibility [which is probably not viable] to manage a heap and avoid fragmentation. I need to think about that some more, but some other ideas have been proposed:

Any subsystem that uses memory buffers could use an MMU to protect them, making them visible only when access is authorized. This might apply to file systems, networking interfaces, inter-CPU communications etc. This is quite a “light weight” application of an MMU [like Thread Protected Mode] and would not impose a significant overhead. The buffers would be protected from malfunctioning or malicious code. Any malware would also need to access the MMU, which, though not impossible, makes life much more difficult for the hacker.

The entire memory of a device could be remapped in a somewhat random fashion. When the device starts up, it would await the instruction and information to unscramble the memory map from a trusted external source. This instruction could be protected using standard [public/private key?] encryption. Using this approach, a device could be stolen and taken apart by someone with criminal intent, but they would have no way to figure out the meaning of the memory contents. Of course, similar results could be obtained using memory encryption, but this requires additional, specialized hardware and introduces further challenges [like debugging].

I would be very interested to hear about other imaginative ways in which an MMU may be employed by email or comment.

[Thanks to Charles, whose comment made me think about revisiting this topic.]