PS3 Cell Processor Security Architecture
hoyhoy writes "IBM Developerworks is discussing the PS3 Cell Processor Security Architecture today on Developerworks. It details the hardware level security for isolating processes that exists in the Cell processor's architecture." From the article: "The architecture's main strength is its ability to allow an application to protect itself using the hardware security features instead of the conventional method of solely relying on the operating system or other supervisory software for protection. Therefore, if the operating system is compromised by an attack, the hardware security features can still protect the application and its valuable data. As an analogy, consider the protection the supervisory software provides as the castle's moat and the Cell BE security hardware features as the locked safe inside the castle."
I'm not really a fan of this sort of design - it seems to duplicate the purpose of the existing kernel/userspace security architecture, but I can appreciate the pickle we're in with de-facto standard kernels that allow anything to be loaded into them. Windows Vista 64 bit requires all kernel drivers to be signed: correctly so, in my opinion, but this doesn't help the huge 32 bit userbase today.
How does it relate to DRM? Can this technology prevent me from doing stuff?
Imagine the Princess inside that Castle.
... or another castle.
--
So who is hotter? Ali or Ali's siter?
Being one of the lucky ones who gets to work on a Cell system, it is becoming painful to come home to my x86 machine that seemed to powerful just a few months ago.
I really hope Sony goes all the way with the stuff Linux desktop stuff they are working on for the PS3. Linux, plus security features like these set forth in the article, make me want a Cell workstation running Linux at home desperately.
If you are any type of game/graphics/engineering/media engineer you want one of these Cell systems NOW.
--
So who is hotter? Ali or Ali's Sister?
Ok, so, I get it. The PS3 will have a processor that has an instruction set dedicated to protected the threads of a program from infiltration by something that has already compromised the operating system. The obvious advantage is the protection of the data stored in those threads at a time of either pre or post processing.
That sounds like a great technology. Truly. If used for the right purposes.
WHY are you implementing it on a GAME CONSOLE? (I'm also a little scared of the wording '...allow an application to protect itself... - we're writing sentience into these things, now, too? Might cause some ethical issues with first-person shooters..)
I'd love that sort of protection on a kiosk machine, something we'd send to a trade show, or even the laptops employed by our sales force. But the PS3? Nothing mission-critical is going to happen on the PS3. Nothing. Wait, wait.. I think I figured it out...
Digital Rights Management. Gotcha, gotcha. Thanks, Sony. It's nice to know that the PS3 will have an anti-modchip on it from the getgo.
Informatus Technologicus
Ah yes, because we know it's all about "US". Security has no other purpose but keeping slashgeeks from their hearts desires. Cold, cruel world.
this "security" would have a backdoor to allow the sony rootkit to be installed
So that means its gonna take mod makers....what...an extra 2 or 3 weeks to crack? Seems like a waste of development money to me
1) The Cell supports a Secure Processing Vault. This is basically hardware-based memory protection; since the OS is software, and software can be compromised, so can the OS. The hardware can't be compromised so easily, so you load up a SPE with some code and data, and then it engages its own memory protection, preventing anyone from reading/writing its memory until it's done, by which time it deletes the important information. So you can't peek at the decrypted results, because they're encrypted when they're loaded, and the decrypted results are deleted when it's done doing its work (which work gets re-encrypted before it leaves the SPE). There's a small communication channel left open, and it's the SPE's duty to protect it.
2) It also has a Runtime Secure Boot. This involves using a cryptographically signed BIOS. This verifies that the BIOS is trusted. From here, any time control is handed over to another program, it first must be cryptographically verified. This prevents unauthorized or compromised code from executing.
3) Once you've securely booted and your SPE is in isolation mode, protected from the eyes of other threads, you have access to The Root Key. The Root Key is stored in hardware, can't be accessed by software, and is used to decrypt other keys. These other keys are then used to do encryption in an individual SPE.
So, we make a key, stick it in some flip flops that you can't read, isolate an SPE to provide memory protection, and then authenticate each and every piece of code from the BIOS through to the currently executing thread. Everything going in is encrypted, isolated when the work is being done, and gets re-encrypted before leaving to the next module, all using encrypted keys. Pretty thick stuff.
:(){
Now, where have we all heard that before? VMS suffered from some pretty cruddy hardware (hey, that was then) but at least buffer overflows were not exploitable.
Nothing new under the sun, move along, nothing to see here.
Do not mock my vision of impractical footwear