Once again, we're a far cry from PS3-Linux-easy, but those 360 kids seem rather hard to dissuade. The latest development on the XeLL bootloader front is that you no longer need a serial cable hooked up for executing the boot loader, all you need is a 360 set up for running burned DVDs, a modified version of the King Kong disc -- you'll want the original game, Windows and a DVD burner to get that together -- and of course a Live CD with XeLL and your Linux distro all prepped to go. By now we're sure we don't need to tell you that this is limited to those lucky 4532 and 4548 kernels, but if you've got all of the above ingredients, plus a little bit of patience and complete disregard for warranty voidance, it looks like Linux on the 360 is within your reach at last. Peep a video after the break of the previous version of XeLL doing its thing.

Overview:
We have discovered a vulnerability in the Xbox 360 hypervisor that allows privilege escalation into hypervisor mode. Together with a method to inject data into non-privileged memory areas, this vulnerability allows an attacker with physical access to an Xbox 360 to run arbitrary code such as alternative operating systems with full privileges and full hardware access.

Technical details:
The Xbox 360 security system is designed around a hypervisor concept. All games and other applications, which must be cryptographically signed with Microsoft's private key, run in non-privileged mode, while only a small hypervisor runs in privileged ("hypervisor") mode. The hypervisor controls access to memory and provides encryption and decryption services.

The policy implemented in the hypervisor forces all executable code to be read-only and encrypted. Therefore, unprivileged code cannot change executable code. A physical memory attack could modify code; however, code memory is encrypted with a unique per-session key, making meaningful modification of code memory in a broadly distributable fashion difficult. In addition, the stack and heap are always marked as non-executable, and therefore data loaded there can never be jumped to by unpriviledged code.

Unprivileged code interacts with the hypervisor via the "sc" ("syscall") instruction, which causes the machine to enter hypervisor mode. The vulnerability is a result of incomplete checking of the parameters passed to the syscall dispatcher, as illustrated below.