The Secure Processing Vault
Goal: isolation of an application
To achieve a secure platform, a processing environment must exist where a single application can execute isolated from all other executing software threads in the system. The Cell BE processor's Vault can provide such an environment. Within the vault, the execution of the application and its data cannot be manipulated or observed -- the hardware design prevents other applications from doing so. For example, digital movie content can be decrypted in, and played from, the vault without the danger of the content being compromised.

its called a VAULT for a reason this is not only software but also dedicated hardware

The goal of isolating a process thread is not new; however, in contrast to the hardware-based method, existing approaches have used software to enforce the separation.  The operating system or the hypervisor (also known as the virtual machine monitor -- the layer of software with the most authority in a virtualized system) has the responsibility of separating processes.  For example, the operating system would ensure that the memory location of the high-value digital content is protected from reads and writes from non-authorized processes.  The problem with this approach is that if an adversary takes control of the operating system or the hypervisor, all bets are off.  The adversary can use the operating system to change the permissions for the memory area it is trying to break into, or simply use the operating system to read the memory location since the operating system can read any memory location in most systems.  In fact, this is why the operating system (or root) is usually the target for hackers and viruses.  An adversary will look for a weakness in the operating system design, such as a buffer overflow vulnerability (see Resources), exploit this hole to gain control of it, and then execute operations that only the operating system has privileges to do.  Within this kind of environment, sensitive data can be easily copied by the adversary-controlled operating system because the memory protection for that data no longer has any effect. The same argument would hold for a virtualized machine where a hypervisor controls the memory accesses of different processes.  If the hypervisor is compromised, whatever protection mechanisms it is intended to provide will not matter anymore.  

The fundamental problem with existing approaches is that they rely on software to provide the isolation, but at the same time software can be manipulated by an adversary.

 A better approach is for the hardware design to isolate the process in such a way that the software cannot override the isolation, and this is precisely what the Cell BE processor's Vault provides.

THIS RIGHT HERE IS VERY IMPORTANT READ IT!

The Vault is implemented as an SPE running in a special mode where it has effectively disengaged itself from the bus, and by extension, the rest of the system.  When in this mode, the SPE's LS, which contains the application's code and data, is locked up for the SPE's use only and cannot be read or written to by any other software.  Control mechanisms which are usually available for supervisory processes to administrate over the SPE are disabled.  In fact, once the SPE is isolated, the only external action possible is to cancel its task, whereby all information in the LS and SPE is erased before external access is re-enabled.  From the hardware perspective, when an SPE is in this isolation mode, the SPE processor's access to the LS remains the same, while on the other side of the LS (the bus side), external accesses are blocked. Thus, all LS read and write requests originating from units on the bus such as the PPE, other SPEs, and the I/O have no effect on the locked-up region of the LS.  However, an area of the isolated SPE's LS is left open to data transfers to and from other units on the bus for communication purposes.  The application running on the isolated SPE is responsible for ensuring that the data coming through the open communication area of its LS is safe.  Also, consistent with the idea that the cores execute independently, any number of SPEs can be in isolation mode at any given time.

Figure 3. The application inside an isolated SPE cannot be observed or modified

NOW READ THIS!

All of this is accomplished exclusively by hardware means; no software, in the form of setting protection bits in an address translation table for example, is involved in the process.  Because of this hardware isolation, even the operating system and the hypervisor cannot access the locked up LS or take control of the SPE core.  Therefore, a hacker who has gained root or hypervisor privileges is not a threat to an application executing on an isolated SPE. The supervisory privileges will not enable him to control the application, nor will it allow him to read or write the memory used by it.  The execution flow and the data of the isolated application are safe.

A hotel analogy clarifies this security model; the hotel manager (PPE) allocates a room (SPE) for a guest (application).  The guest can lock the room from the inside; the hotel manager, and other guests, cannot peek into the room.  However, the hotel manager can kick the guest out.

TO READ MORE

http://www.ibm.com/developerworks/power/library/pa-cellsecurity/

@joeorc - That comment was directed towards some users in this thread unwilling to do any research at all and understand what utter rubbish they were talking. I always take anything I read with a pinch of salt like yourself but there is ways of saying that politely without accusing valued members of the hacking community of being a liar.

There are people in this thread who have, and will never contribute anything to the hacking community running off their mouths too freely imo.

yea, I know i was in 100% agreement with you I was just pointing out like  what you just stated

about how many people can not just blurt out

cannot or will not...its murphy's law

cannot or will not does not apply...