seccomp-based applications analysis and debugging

http://en.wikipedia.org/wiki/Seccomp

http://www.wilderssecurity.com/threads/seccomp-has-been-added-to-the-ubuntu-12-04-kernel.324044/

http://j00ru.vexillium.org/win32k_syscalls/

http://www.wilderssecurity.com/threads/matousec-proactive-security-challenge-64-bits.314015/page-2#post-2021004

https://www.google.com.sg/search?q=seccomp+bpf+example

http://lxr.free-electrons.com/source/samples/seccomp/bpf-direct.c

http://man.cx/?page=prctl(2)

https://bugzilla.mozilla.org/show_bug.cgi?id=790923

https://bug790923.bugzilla.mozilla.org/attachment.cgi?id=780100

http://code.google.com/p/chromium/issues/detail?id=267179

http://lwn.net/Articles/332974/

https://www.imperialviolet.org/2009/08/26/seccomp.html

http://www.insanitybit.com/2012/07/04/chrome-20-on-linux-gives-seccomp-filters-for-flash-3/

https://plus.google.com/+LennartPoetteringTheOneAndOnly/posts/cb3uNFMNUyK

http://security.stackexchange.com/questions/9786/breaking-out-of-a-strict-linux-sandbox-running-virtually-under-windows-do-the-l

http://threatpost.com/using-kernel-exploits-bypass-sandboxes-fun-and-profit-031813/77638

http://stackoverflow.com/questions/14775888/is-there-seccomp-analogue-for-windows

http://blog.cr0.org/2012/09/introducing-chromes-next-generation.html

Hacking through device tree, uboot, and linux kernel setup for Cubox i4-Pro

The following are adding further information to the following wiki pages:

http://imx.solid-run.com/wiki/index.php?title=Building_the_kernel_and_u-boot_for_the_CuBox-i_and_the_HummingBoard

http://imx.solid-run.com/wiki/index.php?title=U-Boot#Files_involved_in_booting

First the Cubox i4 Pro boots from sdcard. u-boot has been modified by SolidRun to generate the initial image for booting: SPL and u-boot.img.
Download the u-boot modified for Cubox:

git clone https://github.com/SolidRun/u-boot-imx6.git

First create the SPL and u-boot.img for flashing into the sdcard (notice that the crosscompiler used is arm-linux-gnueabi-gcc, but I suspect it is possible to use CodeSourcery’s arm-none-eabi-gcc as well, not tested. but the the linux kernel later "arm-none-eabi-gcc was used for compilation):

export ARCH=arm
export CROSS_COMPILE=/usr/bin/arm-linux-gnueabi-

#cd u-boot-imx6
make clean
make mx6_cubox-i_config
make

Next is to flash the SPL and u-boot.img created from above to the SDCARD:

#####DEVICE=/dev/sdb where /dev/sdb is the SDCARD.

dd if=SPL of=$DEVICE bs=1K seek=1
dd if=u-boot.img of=$DEVICE bs=1K seek=42

Next is to download the Linux kernel modified for Cubox (and noticed now the crosstool chain is CodeSourcery’s arm-none-eabi-gcc, please download that first):

git clone https://github.com/SolidRun/linux-linaro-stable-mx6.git
cd linux-linaro-stable-mx6

Ensure /opt/Sourcery_CodeBench_Lite_for_ARM_EABI/bin/ is in $PATH env variable, where the binary arm-none-eabi-gcc, for example, are found.

export ARCH=arm

export CROSS_COMPILE=arm-none-eabi-

make imx_v7_cubox-i_hummingboard_defconfig
make zImage imx6q-cubox-i.dtb imx6dl-cubox-i.dtb imx6dl-hummingboard.dtb
make modules

### ONLY FOR BEGINNING
##make imx_v7_cubox-i_hummingboard_defconfig
make zImage imx6q-cubox-i.dtb imx6dl-cubox-i.dtb imx6dl-hummingboard.dtb
make modules
make modules_install INSTALL_MOD_PATH=mylibmodule

Create the boot.txt file:

setenv bootargs 'root=/dev/mmcblk0p2 console=ttymxc0,115200 video=mxcfb0:dev=hdmi,1920x1080M@60,if=RGB24,bpp=32'
load mmc 0:1 0x18000000 imx6q-cubox-i.dtb
fatload mmc 0:1 0x10800000 zImage
bootz 0x10800000 - 0x18000000

Using "mkimage" command create the boot.scr based on "boot.txt" from above:

mkimage -A arm -O linux -T script -C none -n "U-Boot commands" -d boot.txt boot.scr

Next is to create the uEnv.txt file:

mmcargs=setenv bootargs root=/dev/mmcblk0p2 rootwait video=mxcfb0:dev=hdmi consoleblank=0

Noticed from above that the "root=/dev/mmcblk0p2" is the location of the rootfs, which as the next few lines will show, is the /dev/sdb2 partition of the SDCARD. The above setting was found to work based on the "printenv" output of my Cubox:

printenv ===> (after navigating through the u-boot's output):

mmcargs=setenv bootargs console=${console},${baudrate} root=${mmcroot};

and so on……and anything in uEnv.txt will overwrite the original settings from u-boot.img.

After the "dd" operation on the SDCARD from above, next is to create two more partition for the linux kernel + rootfs:

/dev/sdb1: LABEL="BOOT" UUID="F96B-B2E1" TYPE="vfat"
/dev/sdb2: LABEL="Volumio" UUID="66df47cb-6add-46d3-8178-36cf1e4d2d1a" TYPE="ext4"

Disk /dev/sdb: 7902 MB, 7902068736 bytes
244 heads, 62 sectors/track, 1020 cylinders, total 15433728 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00055ae1

Device Boot Start End Blocks Id System
/dev/sdb1 2048 131071 64512 b W95 FAT32
/dev/sdb2 131072 7716863 3792896 83 Linux

Yes, noticed that /dev/sdb1 starts from sector 2048, whereas the u-boot.img is written onto 84th sector (42×1024=84×512) and writing u-boot.img image and writing to /dev/sdb1 will not overwrite one another.

In /dev/sdb1 the following files are copied:

├── boot.scr
├── imx6dl-cubox-i.dtb
├── imx6dl-hummingboard.dtb
├── imx6q-cubox-i.dtb
├── SPL
├── u-boot.img
├── uEnv.txt
└── zImage

(not all files are used by the u-boot during bootloading, essentially only imx6q-cubox-i.dtb, uEnv.txt, and zImage are used)

The above list of instructions is convoluted and complicated. But if you get stuck somewhere, for example, http://imx.solid-run.com/forums/viewtopic.php?f=17&t=450, there are lots of experimentation and debugging you can do to figure things out (by the way, if you are using "minicom" then better replace it with another terminal – "minicom" will truncate a lot of the u-boot environmental output, misleading me into thinking that the environment variable is not set. I am using "picocom" now, works marvelously):

For example, after connecting Cubox to the PC, via USB, /dev/ttyUSB1 will be autorecognized:

sudo picocom -f n -p n -b 115200 -i -r -l /dev/ttyUSB1

CuBox-i U-Boot > ls mmc 0:1
231452 u-boot.img
35840 spl
230 boot.scr
43388 imx6dl-cubox-i.dtb
43470 imx6dl-hummingboard.dtb
43845 imx6q-cubox-i.dtb
90 uenv.txt
4900544 zimage

8 file(s), 0 dir(s)

CuBox-i U-Boot > load mmc 0:1 0x18000000 imx6q-cubox-i.dtb
43845 bytes read in 17 ms (2.5 MiB/s)

CuBox-i U-Boot > load mmc 0:1 0x10800000 zImage
4900544 bytes read in 308 ms (15.2 MiB/s)

CuBox-i U-Boot > bootz 0x10800000 - 0x18000000
Kernel image @ 0x10800000 [ 0x000000 - 0x4ac6c0 ]
## Flattened Device Tree blob at 18000000
Booting using the fdt blob at 0x18000000
Using Device Tree in place at 18000000, end 1800db44

Starting kernel ...

Trying out the commands successfully as above, now it can be packaged together into the "boot.scr" file using "mkimage" command.

These are the esssential u-boot commands:

ext2load- load binary file from a Ext2 filesystem
ext2ls - list files in a directory (default /)
ext4load- load binary file from a Ext4 filesystem
ext4ls - list files in a directory (default /)
false - do nothing, unsuccessfully
fatinfo - print information about filesystem
fatload - load binary file from a dos filesystem
fatls - list files in a directory (default /)

printenv- print environment variables

setenv - set environment variables

After all the above is the Linux kernel booting up messages:

CuBox-i U-Boot > bootz 0x10800000 - 0x18000000
Kernel image @ 0x10800000 [ 0x000000 - 0x4ac6c0 ]
## Flattened Device Tree blob at 18000000
Booting using the fdt blob at 0x18000000
Using Device Tree in place at 18000000, end 1800db44

Starting kernel ...

Booting Linux on physical CPU 0x0
Linux version 3.10.30-g860304a (tthtlc@papamama) (gcc version 4.8.1 (Sourcery CodeBench Lite 2013.11-24) ) #2 SMP Sun Jun 8 23:08:03 SGT 2014
CPU: ARMv7 Processor [412fc09a] revision 10 (ARMv7), cr=10c53c7d
CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
Machine: Freescale i.MX6 Quad/DualLite (Device Tree), model: SolidRun Cubox-i Dual/Quad
Truncating RAM at 10000000-8fffffff to -7f7fffff (vmalloc region overlap).
cma: CMA: reserved 256 MiB at 6e000000
Memory policy: ECC disabled, Data cache writealloc
PERCPU: Embedded 8 pages/cpu @81715000 s8512 r8192 d16064 u32768

Full details here:

http://pastebin.com/rs1DkzJL

How to root Sony Ericsson Xperia Z (with minimal installation)

Lately I have successfully rooted my Sony Ericsson Xperia Z (firmware version 10.4.1.B.0.101, using Ubuntu 12.04 64-bit + Android SDK):

First, follow the following instruction (from Sony Ericsson) to unlock the bootloader (so that you can install your own custom recovery software):

http://unlockbootloader.sonymobile.com/instructions

As instructed within you have to download Android SDK from google (+ a fastboot USB drivers, if you are on windows, for linux Ubuntu 12.04, the USB drivers is built-in the kernel/distro):

http://developer.sonymobile.com/downloads/drivers/fastboot-driver/ (only for Windows)

Next from the following article:

http://techbeasts.com/2014/02/21/install-cwm-6-0-4-6-recovery-on-sony-xperia-z-c6602c6603-how-to-guide/

I did just this:

1. Download the Z_DooMLoRD_AdvStkKernel_FW-4.3-101_v12.zip, and then the UPDATE-Super-SU:

http://download.chainfire.eu/382/SuperSU/UPDATE-SuperSU-v1.93.zip (whose link is from here:

http://theunlockr.com/2014/03/04/root-sony-xperia-sp-12-1-0-266/

http://theunlockr.com/2014/02/28/root-sony-xperia-z1-compact-android-4-3/

etc) and put the super-su zip file in the Xperia Z’s sdcard.

2. Extract out the "boot.img" file:

-rw-r–r– 1 root root 11313152 Jun 5 00:41 boot.img

md5sum boot.img

8ca52df5bf295631a0bd4dfdf5676baf boot.img

And using "fastboot" to put the Xperial Z into the bootloader mode (the entire screen of Xperia Z is blank black in color, with only the LED light in blue on the top right corner).

3. the using the Android SDK command to install the boot.img as the recovery manager:

fastboot flash boot boot.img

4. Issue "fastboot reboot", and when LED turns pink, immediately click on Volume UP (this sequence is precise and correctly timed, otherwise you will reboot into normal Android normal runtime mode (like me) and has to redo the whole thing again (starting from step 3) and now you will enter CWM recovery screen.

5. In this screen, navigate to the SDCARD where the super-su is located, and install the zip file.

Now you are rooted!! (and only the super-su + boot.img is installed, without the bloat from DOOMLOAD’s AdvStkKernel (:-), but since the CWM recovery manager is installed as well, lots of other stuff can be installed in future….if needed.).

I have done rooting of Nexus 7 (2013, and 2012) as well….another day will elaborate.

Below are collected the references I have consulted:

http://techbeasts.com/2014/02/21/install-cwm-6-0-4-6-recovery-on-sony-xperia-z-c6602c6603-how-to-guide/

http://download.chainfire.eu/382/SuperSU/UPDATE-SuperSU-v1.93.zip

http://forum.xda-developers.com/xperia-z/development/stock-update-to-10-4-1-b-0-101-t2643898

http://www.gameryard.org/2013/03/how-to-root-sony-xperia-z-complete.html

http://forum.xda-developers.com/xperia-z/general/tutorial-root-sony-xperia-z-easy-c6603-t2652152

http://forum.xda-developers.com/showthread.php?t=1886460

http://theunlockr.com/2014/02/28/root-sony-xperia-z1-compact-android-4-3/

http://theunlockr.com/2014/03/04/root-sony-xperia-sp-12-1-0-266/

http://www.teamandroid.com/2014/03/08/root-xperia-z1-c6902-c6903-supersu-official-firmware/

How to: kgdb + QEMU + FreeBSD 10 kernel debugging

First boot up the Freebsd QEMU guest image as per normal:

qemu-system-x86_64 -net user -net nic -m 2048 -hda freebsd10.img -boot c -cdrom FreeBSD-10.0-RELEASE-amd64-dvd1.iso

And copy out the kernel and kernel.symbols file from /boot/kernel directory to the host machine.

Then shut the guest image down, and reboot with QEMU serial debugging enabled:

qemu-system-x86_64 -s -S -net user -net nic -m 2048 -hda freebsd10.img -boot c -cdrom FreeBSD-10.0-RELEASE-amd64-dvd1.iso

When QEMU is "stopped" as displayed, open a separate terminal and use "gdb" in the host machine to connect to the guest:

gdb kernel

where the "kernel" above is the Freebsd kernel file copy out as mentioned earlier. Now followed by two statement below:

target remote localhost:1234

cont

After the guest image has booted up, go back to the gdb terminal and enter "ctrl-C", and there you can set breakpoints.

For example, enter:

rbreak vm_pageout*

And using "bt" for displaying the backtrace after the breakpoint is reached, you can learn a lot of the APIs implementations internals:

For example:

Breakpoint 43, vm_page_requeue_locked (m=0x7e1ed138)
at /usr/src/sys/vm/vm_page.c:2124
2124 /usr/src/sys/vm/vm_page.c: No such file or directory.
(gdb) bt
#0 vm_page_requeue_locked (m=0x7e1ed138) at /usr/src/sys/vm/vm_page.c:2124
#1 0xffffffff80b2187b in vm_pageout_scan (vmd=<optimized out>,
pass=<optimized out>) at /usr/src/sys/vm/vm_pageout.c:1384
#2 vm_pageout_worker (arg=<optimized out>)
at /usr/src/sys/vm/vm_pageout.c:1625
#3 vm_pageout () at /usr/src/sys/vm/vm_pageout.c:1696
#4 0xffffffff8088198a in fork_exit (callout=0x6178490, arg=0x0, frame=0x4)
at /usr/src/sys/kern/kern_fork.c:995
#5 0xffffffff80c758ce in fork_trampoline ()
at /usr/src/sys/amd64/amd64/exception.S:606
#6 0x0000000000000000 in ?? ()
(gdb)

Breakpoint 67, vm_page_insert_radixdone (m=0x7d373f98, object=0x6563c00,
mpred=0x0) at /usr/src/sys/vm/vm_page.c:1015
1015 in /usr/src/sys/vm/vm_page.c
(gdb) bt
#0 vm_page_insert_radixdone (m=0x7d373f98, object=0x6563c00, mpred=0x0)
at /usr/src/sys/vm/vm_page.c:1015
#1 0xffffffff80b1d251 in vm_page_insert_after (object=<optimized out>,
mpred=<optimized out>, m=<optimized out>, object=<optimized out>,
pindex=<optimized out>, mpred=<optimized out>)
at /usr/src/sys/vm/vm_page.c:998
#2 vm_page_alloc (object=0x6563c00, pindex=0, req=<optimized out>)
at /usr/src/sys/vm/vm_page.c:1611
#3 0xffffffff80b0ac13 in vm_fault_hold (map=0x2000000, vaddr=0,
fault_type=2 '02', fault_flags=0, m_hold=0x0)
at /usr/src/sys/vm/vm_fault.c:432
#4 0xffffffff80b0a917 in vm_fault (map=0x0, vaddr=<optimized out>,
fault_type=0 '00', fault_flags=0) at /usr/src/sys/vm/vm_fault.c:224
#5 0xffffffff80c8e83b in trap_pfault (frame=0x937aa970, usermode=0)
at /usr/src/sys/amd64/amd64/trap.c:775
#6 0xffffffff80c8e0f6 in trap (frame=0x0)
at /usr/src/sys/amd64/amd64/trap.c:463
#7 0xffffffff80c75392 in calltrap ()
at /usr/src/sys/amd64/amd64/exception.S:232
#8 0xfffffe0093800000 in ?? ()
#9 0x0000000801808021 in ?? ()
#10 0x0000000000000400 in ?? ()
#11 0xfffffe00937aacc0 in ?? ()
---Type <return> to continue, or q <return> to quit---
#12 0x0000000000000400 in ?? ()
#13 0xfffffe00937aaa50 in ?? ()
#14 0x00007ff7fe7f7f2f in ?? ()
#15 0x0000000000000000 in ?? ()

#0 vm_page_alloc (object=0x6563c00, pindex=0, req=64)
at /usr/src/sys/vm/vm_page.c:1451
#1 0xffffffff80b0ac13 in vm_fault_hold (map=0x2000000,
vaddr=18446741877160935424, fault_type=2 '02', fault_flags=0, m_hold=0x0)
at /usr/src/sys/vm/vm_fault.c:432
#2 0xffffffff80b0a917 in vm_fault (map=0x93800000, vaddr=<optimized out>,
fault_type=32 ' ', fault_flags=0) at /usr/src/sys/vm/vm_fault.c:224
#3 0xffffffff80c8e83b in trap_pfault (frame=0x937aa970, usermode=0)
at /usr/src/sys/amd64/amd64/trap.c:775
#4 0xffffffff80c8e0f6 in trap (frame=0x2)
at /usr/src/sys/amd64/amd64/trap.c:463
#5 0xffffffff80c75392 in calltrap ()
at /usr/src/sys/amd64/amd64/exception.S:232
#6 0xfffffe0093800000 in ?? ()
#7 0x0000000801808021 in ?? ()
#8 0x0000000000000400 in ?? ()
#9 0xfffffe00937aacc0 in ?? ()
#10 0x0000000000000400 in ?? ()
#11 0xfffffe00937aaa50 in ?? ()
#12 0x00007ff7fe7f7f2f in ?? ()
#13 0x0000000000000000 in ?? ()

#0 vm_page_activate (m=<optimized out>, m=<optimized out>)
at /usr/src/sys/vm/vm_page.c:2146
#1 0xffffffff80b0c232 in vm_fault_hold (map=0x2000000, vaddr=<optimized out>,
fault_type=2 '02', fault_flags=<optimized out>, m_hold=0x0)
at /usr/src/sys/vm/vm_fault.c:922
#2 0xffffffff80b0a917 in vm_fault (map=0x93800000, vaddr=<optimized out>,
fault_type=32 ' ', fault_flags=0) at /usr/src/sys/vm/vm_fault.c:224
#3 0xffffffff80c8e83b in trap_pfault (frame=0x937aa970, usermode=0)
at /usr/src/sys/amd64/amd64/trap.c:775
#4 0xffffffff80c8e0f6 in trap (frame=0x2)
at /usr/src/sys/amd64/amd64/trap.c:463
#5 0xffffffff80c75392 in calltrap ()
at /usr/src/sys/amd64/amd64/exception.S:232
#6 0xfffffe0093800000 in ?? ()
#7 0x0000000801808021 in ?? ()
#8 0x0000000000000400 in ?? ()

Compiling u-boot for AMCC Ocotea PPC440GX board

I downloaded the powerpc cross-compiler from:

http://newos.org/toolchains/powerpc-elf-4.8.1-Linux-x86_64.tar.xz

as redirected from here:

http://wiki.osdev.org/GCC_Cross-Compiler

and uboot is from:

ftp://ftp.denx.de/pub/u-boot/u-boot-latest.tar.bz2

Compile for ocotea_config (make ocotea config) after setting ARCH and CROSS_COMPILE environment variable, got a lot of errors:

arch/powerpc/cpu/ppc4xx/built-in.o: In function `spd_read':^M
/home/tthtlc/Downloads/ocotea/u-boot-2014.04/arch/powerpc/cpu/ppc4xx/44x_spd_ddr.c:268: undefined reference to `_restgpr_31_x'^M
arch/powerpc/cpu/ppc4xx/built-in.o: In function `program_tr1':^M
/home/tthtlc/Downloads/ocotea/u-boot-2014.04/arch/powerpc/cpu/ppc4xx/44x_spd_ddr.c:1033: undefined reference to `_restgpr_14_x'^M
arch/powerpc/cpu/ppc4xx/built-in.o: In function `spd_sdram':^M
/home/tthtlc/Downloads/ocotea/u-boot-2014.04/arch/powerpc/cpu/ppc4xx/44x_spd_ddr.c:246: undefined reference to `_restgpr_17_x'^M
arch/powerpc/cpu/ppc4xx/built-in.o: In function `__pci_pre_init':^M
/home/tthtlc/Downloads/ocotea/u-boot-2014.04/arch/powerpc/cpu/ppc4xx/4xx_pci.c:658: undefined reference to `_restgpr_30_x'^M
arch/powerpc/cpu/ppc4xx/built-in.o: In function `pci_init_board':^M
/home/tthtlc/Downloads/ocotea/u-boot-2014.04/arch/powerpc/cpu/ppc4xx/4xx_pci.c:850: undefined reference to `_restgpr_30_x'^M
arch/powerpc/cpu/ppc4xx/built-in.o: In function `checkcpu':^M
/home/tthtlc/Downloads/ocotea/u-boot-2014.04/arch/powerpc/cpu/ppc4xx/cpu.c:647: undefined reference to `_restgpr_28_x'^M

Nonetheless, downloading another cross-compiler from http://ftp.denx.de/pub/eldk/5.3/targets/powerpc/:

http://ftp.denx.de/pub/eldk/5.3/targets/powerpc/eldk-eglibc-i686-powerpc-toolchain-gmae-5.3.sh

and after executing it, the cross compiler is installed in /opt/eldk-5.3/powerpc/ directory.

export ARCH=powerpc
export CROSS_COMPILE=/opt/eldk-5.3/powerpc/sysroots/i686-eldk-linux/usr/bin/powerpc-linux/powerpc-linux-
make ocotea_config
make

The u-boot binaries is successfully produced.

Making the tools – "make tools":

CHK include/config/uboot.release
CHK include/generated/version_autogenerated.h
CHK include/generated/timestamp_autogenerated.h
UPD include/generated/timestamp_autogenerated.h
HOSTCC tools/dumpimage.o
HOSTCC tools/image-host.o
HOSTCC tools/mkenvimage.o
HOSTCC tools/mkimage.o
HOSTLD tools/envcrc
HOSTLD tools/mkenvimage
HOSTLD tools/dumpimage
HOSTLD tools/mkimage

And then compiling for the examples "make examples":

CHK include/config/uboot.release
CHK include/generated/version_autogenerated.h
CHK include/generated/timestamp_autogenerated.h
UPD include/generated/timestamp_autogenerated.h
HOSTCC tools/dumpimage.o
HOSTCC tools/image-host.o
HOSTCC tools/mkenvimage.o
HOSTCC tools/mkimage.o
HOSTLD tools/envcrc
HOSTLD tools/mkenvimage
HOSTLD tools/dumpimage
HOSTLD tools/mkimage
AS arch/powerpc/cpu/ppc4xx/kgdb.o
LD arch/powerpc/cpu/ppc4xx/built-in.o
AS arch/powerpc/cpu/ppc4xx/start.o
CC arch/powerpc/lib/board.o
LD arch/powerpc/lib/built-in.o
CC common/main.o
CC common/cmd_version.o
LD common/built-in.o
CC lib/display_options.o
LD lib/built-in.o
AS examples/standalone/ppc_longjmp.o
AS examples/standalone/ppc_setjmp.o
CC examples/standalone/stubs.o
LD examples/standalone/libstubs.o
CC examples/standalone/hello_world.o
LD examples/standalone/hello_world
CC examples/standalone/sched.o
LD examples/standalone/sched
OBJCOPY examples/standalone/hello_world.srec
OBJCOPY examples/standalone/sched.srec
OBJCOPY examples/standalone/hello_world.bin
OBJCOPY examples/standalone/sched.bin

Finally to flash the uboot to the Ocotea board, which comes default with PIBS bootloader, flash uboot using PIBS bootloader as instructed in:

https://casper.berkeley.edu/svn/trunk/roach/sw/uboot/doc/README.ocotea-PIBS-to-U-Boot

After turning the board off and switching SW1 (U46) to on (= closed) (as instructed in above article), and turning on the power of the board again you should see the following message:


U-Boot 1.1.3 (Apr 5 2005 - 22:59:57)

AMCC PowerPC 440 GX Rev. C
Board: AMCC 440GX Evaluation Board
VCO: 1066 MHz
CPU: 533 MHz
PLB: 152 MHz
OPB: 76 MHz
EPB: 76 MHz
I2C: ready
DRAM: 256 MB
FLASH: 5 MB
PCI: Bus Dev VenId DevId Class Int
In: serial
Out: serial
Err: serial
KGDB: kgdb ready
ready
Net: ppc_440x_eth0, ppc_440x_eth1, ppc_440x_eth2, ppc_440x_eth3
BEDBUG:ready
=>

Next is to get linux kernel porting done.

Checking out the linux kernel 2.6.25 (which does have ocotea.c implemented inside the source code, having been deprecated in the current 3.14 version):

export ARCH=ppc
export CROSS_COMPILE=/opt/eldk-5.3/powerpc/sysroots/i686-eldk-linux/usr/bin/powerpc-linux/powerpc-linux-
make ocotea_defconfig
make V=1
make V=1 uImage

And the following is the partial compiled output:

/bin/bash /home/tthtlc/Downloads/ocotea/kernel2625/scripts/mksysmap .tmp_System.map
cmp -s System.map .tmp_System.map || (echo Inconsistent kallsyms data; echo Try setting CONFIG_KALLSYMS_EXTRA_PASS; rm .tmp_kallsyms* ; /bin/false )
rm -f .old_version
make -f scripts/Makefile.build obj=arch/ppc/boot/images arch/ppc/boot/images/uImage
/opt/eldk-5.3/powerpc/sysroots/i686-eldk-linux/usr/bin/powerpc-linux/powerpc-linux-objcopy -O binary vmlinux arch/ppc/boot/images/vmlinux.bin
gzip -f -9 arch/ppc/boot/images/vmlinux.gz.$$ && mv arch/ppc/boot/images/vmlinux.gz.$$ arch/ppc/boot/images/vmlinux.gz
rm -f arch/ppc/boot/images/uImage
/bin/bash /home/tthtlc/Downloads/ocotea/kernel2625/scripts/mkuboot.sh -A ppc -O linux -T kernel -C gzip -a 00000000 -e 00000000 -n 'Linux-2.6.25' -d arch/ppc/boot/images/vmlinux.gz arch/ppc/boot/images/uImage
Image Name: Linux-2.6.25
Created: Fri Apr 18 23:25:48 2014
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 1118419 Bytes = 1092.21 kB = 1.07 MB
Load Address: 00000000
Entry Point: 00000000
Image: arch/ppc/boot/images/uImage is ready

Learning kprobes internals

First some theory:

http://phrack.org/issues/67/6.html

http://www-users.cs.umn.edu/~boutcher/kprobes/kprobes.txt.html

https://doc.opensuse.org/documentation/html/openSUSE_121/opensuse-tuning/cha.tuning.kprobes.html

http://www.ibm.com/developerworks/library/l-kprobes/index.html

Kprobes tutorial at OLS2006 (with examples):

http://www-users.cs.umn.edu/~boutcher/kprobes/

Lots of pictorial rendering of kprobes:

http://home.eng.iastate.edu/~kothari/LinuxResults/results-2.6.31/globals/kprobe_mutex/index.html

And finally some examples:

http://www.cs.fsu.edu/~baker/devices/lxr/http/source/linux/samples/kprobes/kprobe_example.c

And here is reverse engineering via kprobes in Android:

http://recon.cx/2013/slides/Recon2013-Joshua%20J.%20Drake-Reversing%20and%20Auditing%20Android’s%20Proprietary%20Bits-public.pdf

Tool chain for the TWR-MPC5125

This is a followup to the previous write-up (as some information have become outdated):

http://tthtlc.wordpress.com/2011/01/06/unboxing-my-freescale-board-mpc5125

MPC5125 as provided here:

http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=MPC5125

https://linuxlink.timesys.com/docs/gsg/mpc5125_twr

https://community.freescale.com/thread/74066

http://cache.freescale.com/files/soft_dev_tools/software/board_support_packages/TWRMPC5125LinuxBSP.rar?fpsp=1&WT_TYPE=Board%20Support%20Packages&WT_VENDOR=FREESCALE&WT_FILE_FORMAT=rar&WT_ASSET=Downloads&sr=5

http://www.freescale.com/webapp/sps/download/license.jsp?colCode=CWF-MPC512xADS&nodeId=0127260061033202A5621E&location=overview&WT_TYPE=Board%20Support%20Packages&WT_VENDOR=FREESCALE&WT_FILE_FORMAT=iso&WT_ASSET=Downloads&Parent_nodeId=123481170878772616621E&Parent_pageType=overview

https://community.freescale.com/thread/127394

http://www.freescale.com/files/microcontrollers/doc/fact_sheet/MPC5125FS.pdf

The following is an attempt to recompile the source codes using ELDK toolchain:

https://community.freescale.com/message/342028#342028

I downloaded the following files (from http://ftp.denx.de/pub/eldk/5.3/targets/powerpc/):

eldk-eglibc-i686-powerpc-toolchain-gmae-5.3.sh
powerpc.sha256
target.conf
install.sh

Then I installed them by doing the following:

$ mkdir eldk-download
$ cd eldk-download
$ mkdir -p targets/powerpc
$ wget ftp://ftp.denx.de/pub/eldk/5.3/install.sh
$ cd targets/powerpc
$ wget ftp://ftp.denx.de/pub/eldk/5.3/targets/powerpc/target.conf
$ wget ftp://ftp.denx.de/pub/eldk/5.3/targets/powerpc/eldk-eglibc-i686-powerpc-toolchain-gmae-5.3.sh
$ wget ftp://ftp.denx.de/pub/eldk/5.3/targets/powerpc/powerpc.sha256
$ sha256sum -c armv7a.sha256
eldk-eglibc-i686-powerpc-toolchain-gmae-5.3.sh: OK
target.conf: OK

$ cd ../..
$ chmod a+x install.sh
$ ./install.sh -s gmae -r – powerpc

That resulted in ‘gmae’ selected as the cross compiler toolchain and ‘none’ selected as the root file system (I’m using LimeOS on the development board).

Then I cross-compiled “Hello World” with the following:

$ source opt/eldk-5.3/powerpc/environment-setup-powerpc-linux
$ powerpc-gcc helloworld.c

Follow

Get every new post delivered to your Inbox.

%d bloggers like this: