pwndbg – A nice pluging for GDB

I spend a lot of my day on GDB trying to catch some bugs. I found a very nice plugin for GDB that is helping me a lot, it is called pwndbg.

pwndbg (/poʊndbæg/) is a GDB plug-in that makes debugging with GDB suck less, with a focus on features needed by low-level software developers, hardware hackers, reverse-engineers and exploit developers.

This is the new face for pwndbg. It shows part of the assembly, the source, the stack and the backtrace. It could be redefined if you do not like.

screen

It also has a lot of helpers. The one I found very useful the the register dumps, called `regs`. It show where each register is pointing to. This is an example:

 

regs.png

Anyway, this is a nice tool that might help you on ppc64el debugging. Please find more info about it at:

https://github.com/pwndbg/pwndbg

Advertisements

Float clobbering on inline asm

On inline assembly, I spent some time trying to clobber float registers on inline assembly.

I was trying to clobber a float register, and I was getting:

unknown register name ‘f10’ in ‘asm’

After some debugging I found that the float registers should be clobbered as fr, so, here is an example where we are using and clobbering Counter Register, Conditional register, VSX and FP registers.

asm (
 // prepare to merge low and high
 "mtvsrd 33, %[high_vs0] ;"
 "mtvsrd 34, %[low_vs0] ;"

/*
 * ADJUST vs0 EXPECTED VALUE AFTER AN HTM FAILURE 
 */

// vs0 = 0x5555555555555555555FFFFFFFFFFFFFFFF
 "xxmrghd 0, 33, 34 ;"

/*
 * ADJUST vs32 EXPECTED VALUE AFTER AN HTM FAILURE
 */

// vs32 = 0x5555555555555555555FFFFFFFFFFFFFFFF
 "xxmrghd 32, 33, 34 ;"

/*
 * Wait an amount of context switches so load_fp and load_vec
 * overflow and MSR.FP, MSR.VEC, and MSR.VSX become zero (off).
 */
 "mtctr %[counter];"
 "1: bdnz 1b ;" /*Decrement CTR branch if CTR non zero */

/*
 * Do or don't touch FP prior to the test.
 * set MSR.FP = 1 before provoking a unavailable in TM
 * exception
 */
 "cmpldi %[test_fp],0;"
 "beq no_fp ;"
 "fadd 10,10,10 ;"
 "no_fp: ;"

/*
 * Do or don't touch VEC prior to the test
 * set MSR.VEC = 1 before provoking a unavailable in TM
 * exception
 */
 "cmpldi %[test_vec],0;"
 "beq no_vec ;"
 "vaddcuw 10, 10, 10 ;"
 "no_vec: ;"

/*
 * Perhaps it would be a better idea to do the
 * compares outside transactional context and simply
 * duplicate code
 */
 "tbegin. ;"
 "beq trans_fail;"

/* Do we do FP unavailable? */
 "cmpldi %[exception],%[ex_fp];"
 "bne 1f ;"
 "fadd 10,10,10 ;"
 "b done ;"

/* Do we do VEC unavailable? */
 "1: cmpldi %[exception],%[ex_vec];"
 "bne 2f ;"
 "vaddcuw 10,10,10 ;"
 "b done ;"

/*
 * Not FP or VEC, therefore VSX. Ensure this
 * instruction always generates a VSX Unavailiable.
 * ISA 3.0 is tricky here.
 * (xxmrghd will on 2.07 and 3.0)
 */
 "2: xxmrghd 10,10,10;"

"done: tend. ;"
 "trans_fail: ;"

/* Give values back to C */
 "mfvsrd %[high_vs0],0 ;"
 "xxsldwi 3,0,0,2 ;"
 "mfvsrd %[low_vs0],3 ;"
 "mfvsrd %[high_vs32],32 ;"
 "xxsldwi 3,32,32,2 ;"
 "mfvsrd %[low_vs32],3 ;"

/* Give CR back to C so that it can check what happend */
 "mfcr %[counter];"

: [high_vs0] "+r" (high_vs0),
 [low_vs0] "+r" (low_vs0),
 [high_vs32] "=r" (high_vs32),
 [low_vs32] "=r" (low_vs32),
 [counter] "+r" (counter)
 : [test_fp] "r" (flags.test_fp),
 [test_vec]"r" (flags.test_vec),
 [exception]"r" (flags.exception),
 [ex_fp] "i" (FP_UNA_EXCEPTION),
 [ex_vec] "i" (VEC_UNA_EXCEPTION),
 [ex_vsx] "i" (VSX_UNA_EXCEPTION)

/*
 * It is a mystery to me as to why "f10" doesn't work
 * in the clobbers
 */
 : "cr0", "ctr", "v10", "vs0", "vs10", "vs3", "vs32", "vs33", "vs34", "fr10"

Alpine supports on Power

alpine2bbanner
I am pleased to announce the Alpine Linux distribution has added support for Power systems with the recent release of Alpine 3.6.

Alpine uses different approaches[1] than traditional Linux distros, thus, they were able to build a very small footprint Linux image. Version 3.6 minirootfs for Power contains less than 2Mb[2]. This small footprint capability makes it heavily favored in the containers realm[3].

Please check the Release Notes for the 3.6 release:

https://www.alpinelinux.org/posts/Alpine-3.6.0-released.html

For technical questions, please check the Community page[4].

[1]
https://wiki.alpinelinux.org/wiki/Comparison_with_other_distros
[2]
http://rsync.alpinelinux.org/alpine/v3.6/releases/ppc64le/alpine-minirootfs-3.6.0-ppc64le.tar.gz
[3]
https://store.docker.com/images/alpine
[4]
https://alpinelinux.org/community/

Boot and stop at petitboot

Depending on how you configured your POWER8 petitboot, you might want it to skip the kernel selection and boot on the default kernel.

If your default kernel is having any issue, and you want to re-select it, or, just drop at Petitboot for some other management changes, you can ask IPMI to stops at petitboot, and do not load the default kernel.

In order to do so, you should use the following ipmi command:

ipmitool -H   Host  -I lanplus  -U USER -P PASSWORD chassis bootdev bios

 

Installing NGNIX on FreeBSD/powerpc64

freebsd

As you might know, FreeBSD is also running on IBM POWER8 processor.

I just installed FreeBSD 11.0 on a VM, and installed NGINX. At this moment, FreeBSD does not have the pkg infrastructure for powerpc64, so, you need to use the ports infrastructure to install any software.

I tested it and everything I tried to build (git, zsh, vim, etc) worked fine.

This is the receipt on how to install NGINX after you install the base image:

# portsnap fetch
# portsnap update
# cd /usr/ports/www/ngninx
# make install clean

After that, NGINX will be installed on your system, and you could enable it adding the following line to /etc/rc.conf:

nginx_enable="YES"

 

Setting IPMI Power Restore Policy

If you want to set your Power machine to turn on automatically once it restarts or it is powered up, you can set the IPMI Power Restory Policy

You can choose to keep the machine off, and you need to turn it on manually. You can also choose to power the machine on automatically. The other options involves keeping the previous state, i.e, keep the machine off if it was off before, and vice-versa.

In order to do it, you should use IPMI and point to the BMC, as in the following example, where I set the machine to power on automatically when it is plugged in the power outlet.

 $ ipmitool -H  <x.x.x.x> -I lanplus -U >PASSWORD>  -P admin chassis power on

 

Possible network interface name change after upgrading kernel

Linux kernel 4.4 starts using a mechanism called Network Predictable Naming for the network interfaces. It means the name of network interfaces is based on PCI addresses of the network adapters. For example, an adapter with PCI address 0003:01:00.0 would have a mapped network interface called enP3p1s0f0.

Due to recent changes on Linux kernel to better accommodate the Network Predictable naming in ppc64el architecture, users can possibly experience change in their network interfaces’ names on Ubuntu kernel upgrade to version 4.4.0-36 or subsequent versions.

The solution to this issue is to change the network interface name on file /etc/network/interfaces to fit the new name interface got after the kernel upgrade. After this, for all subsequent kernel versions >= 4.4.0-36 there will be no more naming modifications.

Notice however that booting from old kernel after changing the interface name will present the same issue again!

This issue appears when upgrading from old kernel to 4.4.0-36 and subsequent. Happens on Ubuntu 16.04 and 14.04.5 .

Hint: to show all network interfaces on your system, just issue ls -l /sys/class/net – it’ll show all the interfaces currently available and the symbolic link to their PCI devices.