[DEV][KEXEC/INIT] Photon/Elecrify Kexec and Second Init

Search This thread

phatninja55

Senior Member
Sep 27, 2012
75
49
Hmmm... Seems Electrify does not mount a sdcard at /sdcard? Maybe /mnt/sdcard is the place. Over time I need to know (don't have an Electrify so I dunno how the mounts go).

Thanks for the config, regardless. I'll be working on the kexec-mod build today.

I think, the electrify mounts the sdcard as /sd-ext and internal as /sdcard.
 
  • Like
Reactions: R2DeeTard

tdhite

Senior Member
Dec 4, 2012
1,687
3,463
DFW
I'll be working on the kexec-mod build today.

Ok, folks, I generated a kexec_load.ko module for the Electrify. For the record, the module indeed has a different sys_call_table vector than does the Photon (not unlikely). I built only the 4.5.1A_SUN_USC_19.0 version of the sources, and interestingly, the version magic *does not* match what the folks previously suggested they had after running modinfo. Why we have disparate values is somewhat disturbing, but let's see how this goes with the build pursuant to Motorola's instructions.

First, the requirements we'll always follow:

IF YOU INSTALL THE MODULE, YOU ASSUME ALL THE RISK OF HARM IT MAY CAUSE, IN WHATEVER FORM THAT HARM TAKES. THE MODULE IS A KERNEL LEVEL MODULE AND THEREFORE ANY ERROR IT CAUSES COULD DESTROY YOUR PHONE, BRICK IT, AND THE DAMAGE COULD BE WORSE AND I HAVE NO WAY TO KNOW WHAT IT MIGHT DO. THEREFORE, YOU ASSUME ALL RISK IN USING THE MODULE FOR ANY PURPOSE AND IT IS SUPPLIED "AS IS" AND WITH NO WARRANTIES, EXPRESS OR IMPLIED, NOR ANY WARRANTY OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE, NOR THAT IT WORKS AT ALL.

In short, you agree, completely and utterly, that you cannot hold me responsible for what happens to your phone even if the module actually and proximately causes the harm.

The module specifically for the Electrify is here: https://www.dropbox.com/sh/nra0gpvmdiz2rur/h5hVJkmvRi

As I said, the version magic bugs me -- it says:

filename: kexec_load.ko
license: GPL
depends:
vermagic: 2.6.32.9 SMP preempt mod_unload modversions ARMv7

If you choose to try the load, let me know how it goes and I'll work to fixup probs. We'll work it out ...
 

phatninja55

Senior Member
Sep 27, 2012
75
49
Ok, folks, I generated a kexec_load.ko module for the Electrify. For the record, the module indeed has a different sys_call_table vector than does the Photon (not unlikely). I built only the 4.5.1A_SUN_USC_19.0 version of the sources, and interestingly, the version magic *does not* match what the folks previously suggested they had after running modinfo. Why we have disparate values is somewhat disturbing, but let's see how this goes with the build pursuant to Motorola's instructions.

First, the requirements we'll always follow:

IF YOU INSTALL THE MODULE, YOU ASSUME ALL THE RISK OF HARM IT MAY CAUSE, IN WHATEVER FORM THAT HARM TAKES. THE MODULE IS A KERNEL LEVEL MODULE AND THEREFORE ANY ERROR IT CAUSES COULD DESTROY YOUR PHONE, BRICK IT, AND THE DAMAGE COULD BE WORSE AND I HAVE NO WAY TO KNOW WHAT IT MIGHT DO. THEREFORE, YOU ASSUME ALL RISK IN USING THE MODULE FOR ANY PURPOSE AND IT IS SUPPLIED "AS IS" AND WITH NO WARRANTIES, EXPRESS OR IMPLIED, NOR ANY WARRANTY OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE, NOR THAT IT WORKS AT ALL.

In short, you agree, completely and utterly, that you cannot hold me responsible for what happens to your phone even if the module actually and proximately causes the harm.

The module specifically for the Electrify is here: https://www.dropbox.com/sh/nra0gpvmdiz2rur/h5hVJkmvRi

As I said, the version magic bugs me -- it says:

filename: kexec_load.ko
license: GPL
depends:
vermagic: 2.6.32.9 SMP preempt mod_unload modversions ARMv7

If you choose to try the load, let me know how it goes and I'll work to fixup probs. We'll work it out ...

Good news:
# lsmod
lsmod
Module Size Used by
kexec_load 21792 0 [permanent]
vpnclient 66860 1

Will reboot, and power off. Then tell you whats wrong/right.
Worked, as far as I know. ;)
Didn't show up on reboot or power off. Didn't hang on either.
 
Last edited:

LightingZ

Senior Member
Aug 10, 2011
239
98
Ramat - Gan
Tested the Electrify one it worked!
D:\>adb push kexec_load.ko /data/local/tmp/
839 KB/s (449945 bytes in 0.523s)

D:\>adb shell
$ su
su
# insmod /data/local/tmp/kexec_load.ko
insmod /data/local/tmp/kexec_load.ko
# lsmod
lsmod
Module Size Used by
kexec_load 21792 0 [permanent]
dhd 234239 0
vpnclient 66860 1
#

So we've got module whats next?
 
Last edited:

cmbinf

Member
Sep 18, 2010
27
3
What's next is fixing the segfault in kexec-tools -- it'll take a few days, but thanks for testing.

Sent from my Slim Photon using xda app-developers app

Just wanted to chime-in and confirm on the Electrify(MB853), kexec result...

# lsmod
Module Size Used by
kexec_load 21792 0 [permanent]
vpnclient 66860 1
#

Edit - Question for you tdhite, thought I read somewhere you're using ubuntu 12.04. I haven't used it in awhile and having a little trouble remembering how to pull an system dump on the electrify. Can you give me the terminal comand? I can't remember. Thanks.
Edit 2 - Found what I was looking for Here: http://xdaforums.com/showthread.php?t=1759997
 
Last edited:
  • Like
Reactions: tdhite

twaffle

Senior Member
May 17, 2012
102
74
Derry, NH
It might also be possible to have the existing kexec module, without kexec_tools, to restart *the existing kernel*, however, modifying the kernel command line, allowing initrd to be mounted from someplace else.

I was actually thinking out loud on a couple of ideas. Since kexec modifies the syscall table......

init.c in its main loop calls:

nr = poll(ufds, 3, timeout);

Can you derive the PID of a calling process from a kernel module? It'd be an easier way to hijack, if it is possible, than 2nd-init. Basically, if poll was called by PID 1, block it from ever returning, and exec a new init.

Like I said, this is all more thinking out loud. It did make me ask myself, "Why CAN'T you screw with PID 1?". I mean, it's just a kernel task that launches it. It can't return, but isn't there any way a kernel module can stop it from actually doing anything, and hold it up in kernel land somehow?
 

tdhite

Senior Member
Dec 4, 2012
1,687
3,463
DFW
A kernel module can find the calling process id the process calls the kernel. The kernel is just executing on behalf of the process in that case.

I think it's reasonable to consider a hijack like that. If you want to try it, I can make you a starter module, lemme know.


Sent from my Slim Photon using xda app-developers app
 
  • Like
Reactions: InsanePostman

tdhite

Senior Member
Dec 4, 2012
1,687
3,463
DFW
Oh, and if you read back a ways in the other thread, I was killing init, not just halting it. I see no problem with that since the there never is a chroot that init tries.

Sent from my Slim Photon using xda app-developers app
 
  • Like
Reactions: InsanePostman

tdhite

Senior Member
Dec 4, 2012
1,687
3,463
DFW
Pretty much all I got was a lot of phone hanging, as I noted. But, as the kernel starts the process, it seems plausible to replace it when running in the context of the kernel since cleanup can occur prior to exiting the module call. Not sure, just things to try.

Sent from my Slim Photon using xda app-developers app
 
  • Like
Reactions: InsanePostman

tdhite

Senior Member
Dec 4, 2012
1,687
3,463
DFW
"prWas working on kexec-tools and took a break to kill init to watch. To kill it, you first must poke the process table to set init's flags to allow killing it. The hang comes from the reaper trying to re-parent all the other processes, but no such process exists -- init was stopped.

To fix that, we have to kill all processes and clear any watchdogs that would try to restart them before we can kill and restart init. Not easy, but still a valid rat hole to go down.

Sent from my Slim Photon using xda app-developers app
 
Last edited:

twaffle

Senior Member
May 17, 2012
102
74
Derry, NH
Was working on kexec-tools and took a break to kill init to watch. To kill it, you first must poke the progress table to set init's flags to allow killing it. The hang comes from the reaper trying to re-parent all the other processes, but no such process exists -- init was stopped.

To fix that, we have to kill all processes and clear any watchdogs that would try to restart them before we can kill and restart init. Not easy, but still a valid rat hole to go down.

Sent from my Slim Photon using xda app-developers app

I looked thru the code, and I think this is entirely possible. If the watchdog is the one I think it is, it doesn't actually restart init, it soft resets the kernel itself. However, if this *IS* what is doing on, it's entirely possible to stop the watchdog monitoring.

If you're already in the land of iterating thru init_task, you *should* be able to lock the kernel, and flag each one of the entries and make them all die in one fell swoop (I think).

Even in that case, if you started a new init, it should be able to feed the watchdog itself, so it might not be a big issue to leave the watchdogs enabled. I'm pretty sure it is just looking for something to feed /dev/watchdog. I'm not sure what is actually performing that function....

** Leaving what I typed, but I went looking around **

Ok, this looks to be MUCH easier then I expected!! The panic kicks in here:

http://lxr.linux.no/linux+v2.6.32/kernel/exit.c#L717

Looking around, I wonder if init_pid_ns can be manipulated to 'trick' the kernel into losing track of the init process, creating a new one, and saying 'Yea, that's pid 0, honest!'.

Your doing an awesome job playing around in the trenches, I wish I had more time this week, but the lunch time web searches are all Ive had time to do. That, and I while I have the code downloaded, I don't have enough HD space on my laptop to BUILD it. X-D Need to free some up and increase the virtual box partition size.
 

sonurajput56

Member
Aug 28, 2012
41
7
Ok.. devs.....

Now plz let me know the steps .. for update custom roms in moto photon.. very eager ..


Sent from my MB855 using Tapatalk
 

tdhite

Senior Member
Dec 4, 2012
1,687
3,463
DFW
Hang a bit. Just getting kexec tools running. Not working yet, hopefully tomorrow -- copies that try a reboot into the existing kernel.p

Developers: would like to see if you'd check out the kexec executable. That should have both the module and kexec executable.

That's Photon only, for now. I'll build an Electrify version a little later (I doubt it's different, but because kexec includes header code from the kernel, I find it reasonable to hang just to assure it's no different).

You know the drill, you brick your phone using this, you assume total risk of any harms, including consequential or incidental.

Load the kernel module, and give kexec a whack. It's certainly not done, but at least it runs. To be sure, it will still segfault on exit, but that appears to be an error in the NDK when the 'die' function is called. That just prints things and calls exit(1). The NDK doesn't work like that, but to change how 'die' operates it right now is a ton of work -- not going there yet.
 

phatninja55

Senior Member
Sep 27, 2012
75
49
Developers: would like to see if you'd check out the kexec executable. That should have both the module and kexec executable.

That's Photon only, for now. I'll build an Electrify version a little later (I doubt it's different, but because kexec includes header code from the kernel, I find it reasonable to hang just to assure it's no different).

You know the drill, you brick your phone using this, you assume total risk of any harms, including consequential or incidental.

Load the kernel module, and give kexec a whack. It's certainly not done, but at least it runs. To be sure, it will still segfault on exit, but that appears to be an error in the NDK when the 'die' function is called. That just prints things and calls exit(1). The NDK doesn't work like that, but to change how 'die' operates it right now is a ton of work -- not going there yet.

Every command I try it segfualts. On the electrify, wasn't expecting segfaults but wasn't expecting it to work either. =P
I once tried kexec for another moto phone and it attempted to load the kernel, but didn't. So idk whats wrong here.
 

LightingZ

Senior Member
Aug 10, 2011
239
98
Ramat - Gan
Developers: would like to see if you'd check out the kexec executable. That should have both the module and kexec executable.

That's Photon only, for now. I'll build an Electrify version a little later (I doubt it's different, but because kexec includes header code from the kernel, I find it reasonable to hang just to assure it's no different).

You know the drill, you brick your phone using this, you assume total risk of any harms, including consequential or incidental.

Load the kernel module, and give kexec a whack. It's certainly not done, but at least it runs. To be sure, it will still segfault on exit, but that appears to be an error in the NDK when the 'die' function is called. That just prints things and calls exit(1). The NDK doesn't work like that, but to change how 'die' operates it right now is a ton of work -- not going there yet.
You are a god.
but i have a question i have an au kiddi photon but i flashed Electrify SBF can i use what you posted or may i just wait for electrify?
 

Top Liked Posts

  • There are no posts matching your filters.
  • 32
    This thread includes discussion and work product for porting the kernel kexec facility as a module, and related tools (kexec-tools). The basis is the Eternity project and all git code repositories maintain the history from Eternity.

    The project stems from the desire to overcome the OTA 2.3.5 locked bootloader/signed kernel limitation. More ideas will likely come during the work, but the starting point is clear.

    As for the 'misspell' of Electrify (as Elecrify) -- my apologies to the good folks with that phone. Sheesh! One little typo -- forever it lives.


    Status

    kexec_load.ko:
    The module was modified with the necessary information from the Photon kernel (Electrify to come). It currently loads, and (apparently) runs safely. However, until the kexec-tools (and relevant dependencies) work properly, the module will just sit there. There will surely be bugs as it moves, so don't load it unless you just want to see it load.
    Source code: http://gitorious.org/xda/photon-kexec-mod


    kexec-tools:
    The tools currently build and will run on the phone. The point at which to load kexec, though, remains a work in progress. Kernel loads, atags read in, and initrd reads successfully. Reboot (kexec -e) success remains elusive.
    Source code: https://gitorious.org/xda/photon-kexec-tools


    Second Init:
    Coming soon as we can get it reasonably safe ... check for updates for when code is checked in.


    Kernel and Related Sources from Motorola:
    Photon: http://sourceforge.net/projects/photon4g.motorola/files/
    Electrify: http://sourceforge.net/projects/electrify.motorola/files


    Developer Listing
    tdhite (that would be me)
    twaffle
    Indirect
    more to come... (hopefully)

    I will keep this post up to date with any relevant new information as development progresses.

    For background on getting to this point, please read this thread before posting. Our good friend nickman529 just couldn't stand the OTA mess any longer and asked for a solution. Thanks also goes to our man Indirect for not letting us get away early with a [paraphrasing] "nah -- can't work, right?" attitude. Many others also had many great ideas -- just read the other thread! We don't seek to exclude anyone here.

    Here we go ...
    18
    Folks, our testing failed, but we are not dead yet. The phone reset (full reboot with Motorola logo, so not a simple kernel switch).

    I am pretty sure the module setup the proper jump, but the atags from digging around the boot and image partitions were bogus. Back to finding the correct atags, but at least no bricks! That actually is progress.

    Sent from my Slim Photon using xda app-developers app
    15
    Whoa! Beauty folks.

    I can load the atags from a file with the kexec command. Lemme dig into creating that file. So much thanks. I will probably use the binary dump.

    Everyone run up the messages and throw the thanks at them.

    Let's see where we land now . . .


    Sent from my Slim Photon using xda app-developers app
    14
    so where has the progress reached................ The developers involved in the project seem to be promising...... i hope u people make the bootloader to be unlocked one day..... or at least uboot:thumbup::rolleyes:

    Sent from my Xperia Live with Walkman using Tapatalk 2

    Progress is *terrible* the last two weeks. I've just been crushed at work, so by the time I get into the kernel, my head simply wouldn't compute anymore. I'm back to normal life now, so will get back into it.

    Sorry folks -- some times life just deals a deck not otherwise expected. :)
    13
    One of the possible reasons of this result is the mend is indeed signed and in negative value...Would you mind confirming the definition of the data type of mstart and mend or test with the code below?

    Code:
    fprintf(stderr, "mstart < mend ? 1 : 0 evaluates to %d ...\n", (unsigned long)mstart < (unsigned long)mend ? 1 : 0);

    Turns out there's more to it than that. The kexec-tools code is mixing integer sizes in the math (not likely intended). The critical 'start' point is called 'hole_base,' which was defined as unsigned long, whereas all other vars in the computation were unsigned long long. In any event, fixing up the math the truth shows:

    kernel: 0x40404008 kernel_size: 31eec8
    testing mstart < mend ? afd12c4900000000 < 40000814000000 ...
    mstart < mend ? 1 : 0 evaluates to 0 ...
    mend - mstart = 5795802588100165632 ...
    testing mstart < mend ? afd12c4920000000 < 4000082a000000 ...
    mstart < mend ? 1 : 0 evaluates to 0 ...
    mend - mstart = 5795802587932393472 ...
    testing mstart < mend ? afd12c492a000000 < 40000840000000 ...
    mstart < mend ? 1 : 0 evaluates to 0 ...
    mend - mstart = 5795802588133720064 ...
    Could not find a free area of memory of 326ec8 bytes...
    Cannot load zImage

    Now the question is why on earth we get backward holes (or at least invalid holes) -- that's the next debug. The kernel surely has holes, but there's some sort of disparity between what the kernel knows, as running, and what kexec asks for. I'll see about that later today, hopefully.