Schneier on Security

Clive Robinson • February 9, 2014 11:40 AM

@ Figureitout,

As to technical defeats to your scheme, no I don’t know yet. I’m still rookie there, MMU’s are pretty interesting to me

And so they should be 🙂

If you take a look at an MMU from 20,000ft you see a box with three ports,

1, From CPU Address in.
2, To RAM Address out.
3, Control Port.

Now in a single CPU system the CPU controls it’s own MMU, thus any malware that controls the CPU controls the MMU and thus at best the MMU obsficates the address translation it does not even hide it and certainly does not act as a reliable security mechanism.

Which as the main use for an MMU is Virtual Memory control and to help fast context switching is not an issue.

However ask yourself the question of what happens when the MMU is not controled by the associated CPU but another CPU acting as a security hypervisor?

Malware on the main CPU cannot control the MMU and thus it’s access to memory is controled beyond it’s reach. To change the MMU it has to get the hypervisor to do it, if –and only if– the hypervisor is properly implemented then the malware is blocked from vital parts of memory.

However there is another trick you can do with an appropriate MMU which is “limit memory availability”. Depending on the fine grained control you can get the entire memory range of the CPU limited to just one real RAM address. In practice most MMU’s fine grained control is page based with a page size of 4K, which is not fine grained enough for optimal security.

However if it was sufficiently fine grained you could restrict the amount of real RAM the CPU had access to, and thus not have spare for malware to hide in. With the use of other techniques such as memory usage tagging it would be possible to lock down memory quite well (but not perfectly for reasons I’ll explain in a bit).

Having the ordinary work CPU and a hypervisor alows for an extra trick. As you are no doubt aware most processess in a CPU memory are doing nothing for most of the time, that is they are either blocked or siting in the schedualling que awaiting their run time slice. One thing the hyporvisor or another CPU could do is to check the program memory of the work CPU to see if the static code memory which holds the executable code has changed… if it has then in most instances this would be bad news as it would indicate malware or memory coruption. Either way you would want to treat it as a minimum as a seg fault and clean up and chuck the core image off to another security function for checking.

The “fly in the ointment” for using an MMU for tight memory control is where it is placed, which is generaly on the external memory bus after L1-L3 cache, on most modern CPU’s cache memory far exceeds the real RAM memory on early PC’s (which has malware). Thus in theory malware could bypass the MMU memory restrictions and make it’s self a home in cache memory, but without going into the ins and outs of it, it would not be an easy task to accomplish due to the way associative memory used in cache generaly works.

One way around this is to halt the work CPU and inspect the cache memory (not impossible but…). Another is not to have associative cache or no cache at all, obviously for some types of executable this would involve a performance hit, however often it’s not as bad as portrayed due to the effect of a cache mis on context switching.

The reality is that having more CPU’s without associtive cache memory and thus removing the need for context switching and attendant cache misses can more than make up for the loss of addociative cache, whilst still alowing fairly easy checking of memory for modifications and extra illicit code etc.

One of the things I’ve been thinking about off and on is the amount of silicon wasted for minimal performance gain. One such is “out of order execution”, whilst in theory it has much to offer in practice… It often represents a chunk of real estate that is as large as the actuall core ALU and instruction decode blocks and draws more power and to be honest realy does not pay it’s way when looked at in terms of CPU power and heat budjets.

Thus it could be stripped out and the realestate more usefully employed with a second CPU core. Or it could be if programers could write sensible threaded code, or code blocks small enough to stay within the limits of the core to get better utilisation.

However what if instead of out of order execution some of that real estate was used to provide on the fly cache and RAM checksums to check code memory was not being activly corupted and data memory was staying in range, likewise CPU registers etc?

It’s only by asking these questions in terms of power and heat budjets will acceptable trade offs be found in future silicon real estate. This is because we have already crossed the “terminator line” where all circuitry in a given area of silicon can actually be functioning at full power and speed and not cause “heat death” of the silicon. That is reduction in transistor size is not actually gaining as much usability as it is reduction, and it’s also the reason why things like cache memory is quite large, basicaly the way memory works it’s mainly inactive so it’s power requirment to real estate area is quite small when compared to ALU etc.