Don't concentrate on the IBM docs for their isolation stuff too much - it's mostly useless for the PS3. IBM uses its own isolation loader (which is stored in an OpenFirmware NVRAM variable on isolation enabled blades) and works hand in hand with their own userspace libraries and libspe2. The emulated isolation mode is just a unencrypted version of said isolation loader being loaded into a "normal" SPE. It's nothing the hardware explicitly supports.

Probably the only things that are equal between the IBM implementation and the Sony implementation is the basic setup to instruct the SPE to fetch the isolated binary from memory and enter isolation mode. From there on they're completely different.

Once metldr is running (see spuisolation.tgz floating around somewhere here in the forum) you have to figure out how to communicate with metldr. This could happen via the mailbox of the isolated SPE or via the small LS window that remains accessible even in isolated mode. The easiest thing to try would be to load one of the loaders (lv1ldr, lv2ldr, appldr) into memory and try to pass that address to metldr. Take care to align your binaries to 16 byte boundaries in memory or else the DMA will fail.

This could happen via the mailbox of the isolated SPE or via the small LS window that remains accessible even in isolated mode.

According to the cbe architecture pdf "SPU_LSLR - SPU local storage limit register - When an isolation load is requested, the contents of the SPU_LSLR are forced to the maximum value for the implementation."
Not offense but to clearing things...

I've got confirmation this is also on Mercury products(PCIe-host, Server,Ruggadized box). I'm assuming on all other server blades too.

In theory you'd reverse the SDK call, and see how it uses the syscall(s), then from the dump analyze syscall(s) and code a interface. This is pretty much what has to be done if anything code related is going to be done.

According to the cbe architecture pdf "SPU_LSLR - SPU local storage limit register - When an isolation load is requested, the contents of the SPU_LSLR are forced to the maximum value for the implementation."
Not offense but to clearing things...

That register only affects the size of the LS as seen by the SPU - it has nothing to do with the access restrictions enforced during isolation mode. When in isolation mode, the SPU still has full access to the LS.

See CBEA v1.02 p241:

If an application performs a quadword load or store from the SPU beyond the range of the SPU_LSLR, the operation occurs at the resulting wrapped address.

SPU_LSLR being pushed to the maximum value on entering isolated mode actually does nothing since the maximum value is 0b111 which equals 256 KiB and is set as the default value on system start.

When initiating a transition into an SPU isolated execution environment and while operating in this environment, an area of local storage starting at address zero is isolated from the system (this area is called the isolated local storage area or the isolated area). Only the associated SPU can access the isolated area. Access from all other processors and devices in the system must not be allowed. The size of the isolated local storage area is implementation dependent. The remaining area, or open area, of local storage is not isolated and remains accessible. The open area can be used for data transfers, control, and communications between the rest of the system and the SPU operating in the SPU isolated execution environment.

sorry, these documents are confusing as hell (i remembered something about and have forgotten to reread thoroughly)

now back to the topic: the CBE_Sevure_SDK_Guide looks like containing at least the essence of the communication, but the sony's implementation may be differ (a little)... but with that, i didn't say anything new

Yeah exactly - since we're dealing with a (completely) different isolation loader for the non Sony products, examining their communication protocols can merely serve as a source of ideas how it could be done.

And I really mean all non Sony products. The Mercury server blades are essentially re-branded IBM QS21/22. Their 1U server is a Blade in a 1U case and the PCIe cards are also OEM IBM

Mercury might have developed its own security SDK but I doubt it - why re-invent the wheel when the IBM SDK is already available an tested on their hardware?

Same thing for MatrixVision and Fixstars stuff. Up until now, Sony, Toshiba and IBM are the only manufacturers of Cell based HW (maybe with the exception of the ruggedized Mercury box).

One thing to try and find out might be if the Sony 1U server has isolation support.

Fortunately, the task at hand is in principle an easy one. METLDR has to know where the binary it should decrypt is located (and maybe where to put the decrypted data). We have two possible communication channels available. So we already know the what and where. Problem is the how (communication protocol).

Simplest thing to try would be passing the locations of two buffers (source and target in both possible orders) either via mailbox or the open LS window and see if anything (usable) hits the target buffer.