otheros/file.bin?

[lotharx]

Hey can anyone make a bare loader in C++? I looked at the otheros.bld/demo.bin demos and they where riddled with bit mapping code. I was thinking maybe something that used the BIOS font to output a simple text string.

It'd probably help a lot of people who don't want to tear apart kboot when someone else already has. The rest can be figured out.

[mc]

There is no "BIOS font". A PS3 is not a PC.

[lotharx]

There is no "BIOS font". A PS3 is not a PC.

ohh..usually systems have a font for the BIOS, or at least I thought they did.

Are you allowed to share the makefile for your last otheros demo?

EDIT: Never mind I eventually figured it out. If anyone wants a script to compile it, and a hello world otheros.bld demo to build off of, just PM me.

[mc]

There isn't even a "BIOS". There is only the Hypervisor, but the services it provides are
somewhat different from those of a PC BIOS. It can setup the screen video mode for you,
it can map the hardware frame buffer into your address space, and it can copy blocks of
data from CPU memory to video memory. But it can not draw text for you, and so it
does not need any font.

[lotharx]

There isn't even a "BIOS". There is only the Hypervisor, but the services it provides are
somewhat different from those of a PC BIOS. It can setup the screen video mode for you,
it can map the hardware frame buffer into your address space, and it can copy blocks of
data from CPU memory to video memory. But it can not draw text for you, and so it
does not need any font.

I've noticed the NAND hypervisor claim is still floating around here. Has anyone here looked at the IBM pages and QS20 docs?

IBM engineers say The CBE and it's local store per SPE are the hypervisor(The original Type I reference would reinforce that information.) The NAND holds IBM/Sony/Toshiba/Nvidia code- key point is the IBM/Sony/Toshiba jointly developed crypto library that uses the CBE root key.

I'm not going to continue to rant because the IBM site is on the tip of noses, and I have noob status here so it's getting ignored anyway.

[mc]

Um. I'm not sure what you're trying to say here.

Hypervisor is an execution state in the PPU, above both the "problem state" and
"supervisor state". It is controlled by the HV (for HyperVisor) bit in the MSR. (See
PowerPC architecture manuals) It has nothing in particular to do with NAND or
SPE local store.

When we talk about "the hypervisor", we refer to the code which is running
in hypervisor state, typically as the result of an "sc 1" instruction.

[lotharx]

Um. I'm not sure what you're trying to say here.

Hypervisor is an execution state in the PPU, above both the "problem state" and
"supervisor state". It is controlled by the HV (for HyperVisor) bit in the MSR. (See
PowerPC architecture manuals) It has nothing in particular to do with NAND or
SPE local store.

When we talk about "the hypervisor", we refer to the code which is running
in hypervisor state, typically as the result of an "sc 1" instruction.

I know what you're talking about now. On the IBM pages they mention a bit field(MSR equivalent?) though that holds a lock state for each SPE. I guess that works post PPU state layout for the extra security.

Still doesn't explain how secure boot works though. Supposedly the first piece of code loaded from NAND at power up has a check sum that is within the CBE to prevent tampering and create a secure processing model. Only thing I see being logical is the code self modifies with the encryption library using the SHA1 functionality at load time. That would mean the bases of the security model was just obfuscated code in NAND.

I'm going to go read up on old Mac security. Also I might try to modify the code I have so far to display stack regions from within it's own store.

Also I seen in the Linux kernel everything is "lvl1" and on IBM somewhere I seen reference to a "lvl2" and others I think. That would indicate lvl1/otheros is running in a NAND based VM wouldn't it?

[mc]

The "lock" on SPEs is called "isolation mode", and is unrelated to the hypervisor state.

I don't understand why you are bringing in "secure boot" into this. otheros.bld is
loaded into the virtualized machine which is seen from the supervisor and problem
states. At that time, the real system is already "booted", in the sense that all the
hypervisor code is already loaded (from NAND or whatever) and active. Presumably
the system SPE already has whatever code it needs, and is running in isolation
mode, at this time as well, but I haven't checked.

Since otheros.bld is running in a virtualized machine, you will not find anything in the
memory except the contents of otheros.bld itself, so trying to find someone elses
stacks is a waste of time.

[IronPeter]

This page
http://www.ps3news.com/tag/bootup
says how the boot proccess looks like.

The SCC (Super Companion Chip), made by Toshiba gets the PS3 started up. It reads asecure_loader from flash, and loads it into SPE in isolation mode. The Flash reading is interesting, as the data on the flash chips are interleaved, so the SCC merges them, among other things.

asecure_loader is then decrypted and ran, and it brings up lv1ldr. The keys for self decryption (among other things) are most likely accessible at this time.

lv1ldr is then decrypted and ran, and verifies the integrity of lv1.self , decrypts and runs it.

lv1.self is most likely our base code, also known as the Hypervisor. The Hypervisor then calls lv2ldr.

lv2ldr is ran, and it runs lv2_kernel.self

[mc]

It also says that lv2_kernel.self is the GameOS, so presumably it is not loaded at all when
the system is configured for OtherOS operation, but only the lv1 stuff. And that would
be why the Linux code only contains lv1 calls; there is no lv2 loaded to call.