On Thu, 2006-07-27 at 13:53 -0400, Reiner Sailer wrote:

_If_ you want to trust the whole chain from the device driver through an unaudited binary blob on your motherboard or controller card to the disk drive to map logical volumes into hardware storage devices _then_ the separation / confinement can happen on the logical level. If not then you can do the kind of encryption that I suggested.

No, I'm really thinking about a practically useful level of assurance. RAID controller errors are a real problem in real life. There is a need to encrypt data written to disk for confidentiality purposes. CPUs are rapidly gaining cores that might take on encryption tasks. It all seems entirely reasonable to me.

If you lose a drive without RAID, you'll lose all your data. If you lose a drive with RAID, you'll get most of it back. The RAID implementation doesn't have to be perfect to achieve that. A lot of RAID implementations aren't perfect but they still have market share. It's not black and white.

You have to trust the CPU to maintain isolation between domains so you might as well use that, right?

On the one hand there are different kinds of applications and on the other, the different level of assurance you might want in your data centre.

Say you have a cluster of xen machines with a single point of management for the cluster. If any individual domain goes down then you lose one server but if the cluster as a whole goes down then you lose a big chunk of your data centre. You might be inclined to run the software that is managing your data centre inside a domain with very high levels of protection from, for example, erroneous devices. It's not particularly performance critical so you might as well.

Similarly, if someone gains access to the single point of management that controls your data centre then they gain access to all your servers and all your data so that's another reason why you might choose to run that kind of code inside a domain with very high levels of assurance.

Harry.