How to build a paxctl (or chpax) for other ABI's ELF files?

[Neokernsec]

I'm trying to build a version of paxctl (or chpax) that will let me change PaX ELF flags for any ABI's binaries, without success.

I've tried a variety of "cross compilation" and different embedded "hosting" solutions, but at the end of the day, I can't get an x86 version that accepts MIPS 32bit ELF files as "valid".

I am building MIPS binaries under x64, and for a variety of reasons a "native" (MIPS) version of paxctl/chpax won't work for me - paxctl's reliance upon mmap() and friends precludes its use on filesystems like jffs, etc.

Do you have any suggestions as to where I might start to build a "cross-hosted" tool whereby I could alter MIPS ELF binaries on an x64 host?

[PaX Team]

paxctl should work fine on any ABI but it has very strict checks on the target files. i just checked busybox on a random openwrt/MIPS box and even 'file' itself reports it as having a 'corrupted section header size'. so either fix your binaries or relax the paxctl checks (but if it then breaks your binaries you get to keep both pieces ).

[Neokernsec]

Ah, so they are. It turns out the culprit is OpenWRT's use of sstrip (versus strip), which seems to slightly damage the ELF binaries, even if it does reduce their size a bit better than strip does.

Thanks for the heads up. I didn't even think to check their validity, doh.

[PaX Team]

paxctl should work fine on any ABI but it has very strict checks on the target files.

actually, this is not quite true, paxctl ignores endianness (the manpage explicitly mentions the amd64/mips case) so the host and target must be the same otherwise the results won't be good... (and yes, patches are accepted )

[Neokernsec]

Ah yes. Switching to strip doesn't address the problem., but it does make file happy.

$ file randheap1
randheap1: ELF 32-bit MSB executable, MIPS, MIPS32 rel2 version 1 (SYSV), dynamically linked (uses shared libs), stripped
$ chpax -v randheap1
randheap1: Unknown file type (passed)
$ paxctl -v randheap1
file randheap1 is not a valid ELF executable

Rats.

I'll throw some time at the problem to see if there's a straightforward fix.

My main reason for doing this is that paxctl's use of mmap() causes it to be broken when ELF files are on filesystems that do not support writably mmap()ed files.

So it'll probably come down to which is the speediest-to-deploy: de-mmap()ing paxctl or adding MIPS32 ELF support for the x86/x64 hosted tool.

I realise the Final Solution is to add support for all of the ELF flavours to it, but that sounds like a Big Job(tm) that is thoroughly UnSexy(tm) and Thankless(tm).

[PaX Team]

the quickest approach is definitely to replace mmap/munmap with malloc/read/write/close or so. fixing up the endian-sensitive accesses is a whole lot more work (perhaps a gcc plugin one day to automate it ).