SPE ISOLATION MODE
At the heart of CBEs security architecture is the ability to isolate an SPE from the rest of the system. This is accomplished by one, locking up the isolated SPEs LS for its own use only, and two, disabling all external execution path control of the SPE core. Specifically, all LS read and write requests originating from units on the EIB such as the PPE, other SPEs, and the I/O do not have any effect on the locked-up region of the LS. There is a small area of the LS left open to both the external agents and the SPE for communication purposes. And, the isolation mode disables the ability for a supervisory process to set or read the program counter of the SPE. Once the SPE is isolated, the only external action possible is to cancel its task, whereby all data in the LS and SPE are erased before external access is re-enabled.
All of this is accomplished exclusively by hardware means; there is no software (in the form of setting protection bits in a table for example) involved in the process. Because of this absolute 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 from manipulation, snooping, and modifications.
Using this capability, a CBE system can achieve the seemingly contradictory goal of protecting a user while simultaneously limiting that users ability to infringe upon the security of others. Sensitive private information such as the users passwords or credit card numbers can be designated to only be in the clear within an isolated SPE. At the same time, digital entertainment content can be protected from malicious users by always decrypting within an isolated SPE.
HARDWARE ROOT OF TRUST
Due to the malleability of software, it is generally believed that the root of an authentication scheme must be implemented in hardware. If the root can be trusted, then the entity authenticated by the root can be trusted, and so on as the chain of trust expands.
The CBE has a cryptographic-based hardware authentication mechanism that can be used as a foundation of a trusted software stack. The hardware verifies the integrity of the first software module, and in turn, this software module verifies the integrity of a secondary software module. Because the hardware cannot be modified, its operation can be trusted and because the integrity of the first software module was verified by this trusted party, its operation can be trusted, and so on.
This hardware authentication mechanism is activated every time an SPE enters isolation mode. Specifically, the first code module to run during an isolated SPE session has its integrity checked by the hardware root of trust before it is executed. Thus, much like the two parts of an inductive proof, if the SPE isolation mode protects the softwares execution, then, the hardware root of trust ensures that the softwares initial state is correct.
)... Hdd playing would be cool too... My old ps1/ps2 CDs can't take care of themselves alone... :/
