Estimate of performance improvement when HV is disabled

[amadeus]

Hi,

I was wondering, if anyone have an estimate of the performance drop because of the hypervisor? Are we talking about 1%, 5%, or 10%?

If the hypervisor is disabled, would that make the games faster, or does it not work like that?

[Arakon]

if the hypervisor was disabled, the system wouldn't run anything.

[Ell3X]

here a little bit more information about the xbox 360 hypervisor

http://www.xbox360fanboy.com/2005/11/29/the-hypervisor-and-its-implications/

[amadeus]

Thanks for that one 

I assume, that the biggest problem is, that the kernel needs to be signed by MS?

But if that is not the case, would it then be possible to develop a kernel without a HV?

[tmbinc]

Sure, linux for example doesn't use a hypervisor.

Still the hypervisor act as part of the OS. the functions need to be there. If they wouldn't be in the HV, they would be in the supervisor. What you could save would be the mode switch at the syscalls. But the syscalls are not called in performance critical tasks, so my guess is: <1%.

What might impact performance is the memory encryption and checking. But according to the sources we know, the impact is minimal because the latency of the decryption is largely hidden by the l2 cache latency (however this works).

[amadeus]

That's pretty impressive 

Is the memory also encrypted when running Linux?

Would it be possible to develop a new (open source) kernel?

[aegzorz]

The Linux kernel IS open source

[amadeus]

The Linux kernel IS open source

What??? Just kidding 

Unfortunately won't the Linux kernel fit in the flash.

I was fishing more after what sort of modifications that don't need signing from MS. Hence, can we e.g. modify the kernel?

[aegzorz]

The linux kernel should fit nicely in the flash, just that we can't load it directly because of the signatures.
The signatures also prevents us from replacing the existing kernel, that's why we need the vulnerable 4532/4548 to run unsigned code.

[amadeus]

The linux kernel should fit nicely in the flash, just that we can't load it directly because of the signatures.
The signatures also prevents us from replacing the existing kernel, that's why we need the vulnerable 4532/4548 to run unsigned code.

Okay thanks for that.

It would be so cool, if we could use the HV to return a different signature (ours) instead of MS's...

[Redline99]

If you could change the HV to skip the Kernel sig then great, but how are you going to change the HV without breaking it's sig? Everything is checked in the bootloaders from 1bl to fully running. You have to break that chain of trust somewhere to get unsigned code to execute.

[amadeus]

If you could change the HV to skip the Kernel sig then great, but how are you going to change the HV without breaking it's sig? Everything is checked in the bootloaders from 1bl to fully running. You have to break that chain of trust somewhere to get unsigned code to execute.

I now understand the problem...

Although it is not clear to me, how the kernel is patched up from 1888 to current, and the signature is still valid.

Is it due to some mathematics like super position that ensures that the new (patched) kernel also have a valid signature?

[tmbinc]

No, it's just that the base kernel (1888) signature must be ok (technically speaking: the signature of the loader of the kernel must be ok (2BL). The loader then checks the hash of the next loader (4BL)/kernel(5BL), which must match).

Then, the 4BL (i.e. the program which unpacks the kernel) checks, after the base kernel was extracted ok, if the signature of the patcher (6BL) is ok. The patcher is a program which applies the difference to the updated kernel (7BL) against the base kernel. Thus, an updated system has two signatures: one for the base kernel (which is always the same), and one for the upgrade. The upgrade of course is delivered already in a signed form.

[Redline99]

oh and the HV/Kern are packaged in the same section covered by the same sig etc... And I was over simplifying the explanation.   

[amadeus]

No, it's just that the base kernel (1888) signature must be ok (technically speaking: the signature of the loader of the kernel must be ok (2BL). The loader then checks the hash of the next loader (4BL)/kernel(5BL), which must match).

Then, the 4BL (i.e. the program which unpacks the kernel) checks, after the base kernel was extracted ok, if the signature of the patcher (6BL) is ok. The patcher is a program which applies the difference to the updated kernel (7BL) against the base kernel. Thus, an updated system has two signatures: one for the base kernel (which is always the same), and one for the upgrade. The upgrade of course is delivered already in a signed form.

So how to they ensure the integrity of the 2nd signature? Have they signed the 2nd signature? And if so, is the component that does that check signed its self?

[Redline99]

From my limited understanding, the chain of trust starts with the 1bl which is inside of the cpu. Then the 2bl is is loaded from flash. Then the 1bl validates the 2bl before the 2bl gets to run.  The 2bl then validates the next section before it gets to run, etc... Since the 1bl is started automatically from the cpu rom, that makes it hard to start any naughty business.

[tmbinc]

amadeus: Please re-read my post. The first signature (of 2BL) is checked in 1BL (ROM), the second signature (of 6BL) is checked in 4BL. 4BL itself is hashed and checked by 2BL, which is signed.

So yeah, chain of trust: 1BL -> 2BL -> 4BL -> 5BL  and 4BL -> 6BL -> 7BL. 5BL is base kernel, 7BL is the difference to the final kernel.

[amadeus]

Thank you very much for the visuals and explanation.

I now understand the problem, and have no more questions