Kexec Progress = Custom Kernels and Fully Functional CM/AOSP ROMs

[orangechoochoo]

I don't see it discussed here much but the developers were able to get kexec working on the Razor. Kexec allows the loading of custom kernels.

"Description

kexec (kernel execution) is a system call that enables you to load and boot into another kernel from the currently running kernel. kexec performs the function of the boot loader from within the kernel. The primary difference between a standard system boot and a kexec boot is that the hardware initialization normally performed by the BIOS or firmware (depending on architecture) is not performed during a kexec boot."

To sum it up, with kexec it does a reboot and bypasses the signature verification and allows you to load a custom kernel on a system with a locked bootloader such as ours.

What does this mean for us? We can use the full CM & AOSP roms with their corresponding kernels! Since we have locked bootloaders that won't allow us to load unsigned (custom) kernels, the current batch of CM & AOSP roms must be tweaked to run on the stock rom. That's why development & ironing out bugs takes a while. It's analogous to making ICS roms work on GB kernels; very problematic.

So stay tuned, over the coming months we will see full CM & AOSP roms being released, and it's been said JellyBean will be truly JB instead of a version that is tweaked to run off an ICS kernel.

 

[outsid0r]

and heres the obligitory ETA???? that would follow no matter what... lol

 

[orangechoochoo]

Once news of this came out the dev's twitter page was inundated with ETA requests so he disappeared to work on it in silence.

 

[JKingDev]

Once news of this came out the dev's twitter page was inundated with ETA requests so he disappeared to work on it in silence.

As I understand it, hascode was working on a universal kernel to work on D3, Razr, and D4. He was working and testing on a D3 and once he had the D3 kernel functioning he would move on to making sure everything still worked on D4 and Razr. He has everything working on D3 except the cameras. Looks like the method he was originally using to make the cams work is a dead end so he is trying a new method now. [twitter]

 

[crockettc1]

Hashcode has said (per his Twitter account) safestrap v2.1 is available with Kexec support. Does that mean we'll be seeing custom kernels bundled with ROMs in the near future?

 

[orangechoochoo]

Yup, just as they were meant to be.

 

[JKingDev]

General question about kexec, is it an api call that must be included in the stock ROM in order to be utilized or can it be compiled from linux source code and executed on any ROM? So basically, can manufacturers leave out kexec support from devices in the future to prevent people from booting custom kernels this way, or is this something the stock ROM cannot stop (provided you have root access to the system)? This is a very cool method.

 

[tcrews]

Kexec is a feature of the kernel. If it's possible to compile an Android boot kernel without kexec I do not know.

Basically the phone/device is booting normally then an intercept is setup to reboot the kernel but instead of reloading the stock kernel an alternate kernel is used.

I believe it was a fast "rebooting" method for Linux to test kernel code changes allowing an almost instant reboot in to a "new" kernel without an entire system restart...

eh....Wiki:

[h=1]kexec[/h]From Wikipedia, the free encyclopedia

http://en.wikipedia.org/wiki/Kexec#mw-headhttp://en.wikipedia.org/wiki/Kexec#p-search
In computing, kexec (kernel execution) is a mechanism of the Linux kernel that allows "live" booting of a new kernel "over" the currently running kernel. kexec skips the bootloaderstage (hardware initialization phase by the firmware or BIOS) and directly loads the new kernel into memory, where it starts executing immediately. This avoids the long times associated with a full reboot[SUP][1][/SUP], and can help systems to meet high-availability requirements by minimizing downtime.
While feasible, implementing a mechanism such as kexec raises two major challenges:

1. the new kernel will overwrite the memory of the currently running one, while it is still executing
2. the new kernel will usually expect all physical devices to be in a well-defined state (as they are after system reboot, when the BIOS (or firmware) resets them to a "sane" state). Bypassing a real reboot may leave devices in an unknown state, and the new kernel will have to recover from that.

 

[JKingDev]

Kexec is a feature of the kernel. If it's possible to compile an Android boot kernel without kexec I do not know.

Basically the phone/device is booting normally then an intercept is setup to reboot the kernel but instead of reloading the stock kernel an alternate kernel is used.

I believe it was a fast "rebooting" method for Linux to test kernel code changes allowing an almost instant reboot in to a "new" kernel without an entire system restart...

eh....Wiki:

[*]
[/LIST]
[/FONT][/COLOR]

Yeah its an intriguing method. I am just wondering if future devices could be released without support for kexec to block this. If the kexec routine can be compiled from source and executed on any ROM this would be a beacon of hope against locked bootloaders. Then all we have to worry about is driver support.. I am sure they will come up with some tricky way to screw us.