ARM BE8 cannot be lifted: instruction and data endianness are not separable

[zardus]

THIS MESSAGE WAS GENERATED BY AN AUTOMATED PROCESS

ARM BE8 objects decode as garbage, because instruction endianness and data endianness cannot currently be set independently. Measured against the binaries' own symbol tables across a large corpus, this is 10 objects and 706 function symbols with no block at their entry.

In BE8, data is big-endian but instructions are stored little-endian. CLE does not read EF_ARM_BE8, and ArchARM with memory_endness big means BE32, so instruction words are fetched byte-swapped and almost nothing lifts.

The awkward part is below archinfo. libVEX's ARM front end fetches instruction words through the same endness the guest state uses — guest_arm_toIR.c reads them with getUInt under archinfo->endness — so a single VexEndness drives both, and there is no knob to split them. pyvex already defines ARCH_ARM_BE_LE for exactly this case, but nothing selects it and libVEX has no corresponding mode.

So the options seem to be a libVEX change that separates instruction fetch endianness from data endianness, a pyvex-level pre-swap of instruction words before lifting, or leaving BE8 unsupported but detected, so CLE reports it rather than producing an empty CFG.

Any ARMv7 big-endian toolchain reproduces it: BE8 is the default for big-endian ARMv7, and the resulting binary has EF_ARM_BE8 set in e_flags.

[zardus]

THIS MESSAGE WAS GENERATED BY AN AUTOMATED PROCESS

A wider sweep gives this a much larger scope than the ten objects the issue was filed on.

Across 50,956 scored objects, 662 are big-endian ARM (660 ELF, 2 raw blobs), and between them they miss 4,016 of their 4,554 sized function symbols — 88% of the code their own symbol tables describe. That is 37.3% of every missed-function instance in the sweep, from one architecture configuration.

Four representative objects, all ARMHF loaded big-endian:

object	sized function symbols	no block covers them	blocks recovered
f7df7666…	905	800	652
178e80e1…	756	663	662
776adfdd…	674	595	449
db24c1f2…	504	444	359

Two details that distinguish this from ordinary under-recovery. The measure counts a symbol as missed only when no block covers the address at all, not merely when no block starts on it — so these are not boundary-attribution differences. And the companion counter for "covered by a block starting earlier" is 0 or 1 on every one of these objects, so nothing is being recovered slightly off; it is simply absent.

That is what BE8 predicts: instructions are stored little-endian while data is big-endian, ArchARM with big memory_endness means BE32, so instruction words are fetched byte-swapped and almost nothing lifts. The objects still produce a few hundred blocks each, which is why this does not show up as a load failure or a crash — it looks like a successful analysis that happens to find very little.

No opinion here on which of the three approaches in the issue is right; the choice still needs a maintainer. This is only to say the population affected is larger than it looked.

[zardus]

THIS MESSAGE WAS GENERATED BY AN AUTOMATED PROCESS

I built a working prototype of all three ends of this and measured it. Summary: BE8 is fixable and the fix works, but it needs two decisions that are not mine to make, and one thing in this issue and in my earlier comment needs correcting.

ARCH_ARM_BE_LE does not do what its name says, and neither does ARCH_ARM_BE

instruction_endness is read in exactly one place, pyvex/lifting/util/instr_helper.py. Nothing on the libVEX path looks at it: LibVEXLifter._lift passes arch.vex_arch and arch.vex_archinfo, and the only endness libVEX ever sees is vex_archinfo["endness"], which is set from the memory endness. Lifting the same bytes with ARCH_ARM_BE_LE and with a plain PyvexArch("ARM", 32, "Iend_BE") gives byte-identical IR.

So ARCH_ARM_BE_LE is a BE32 arch, and its own test says so:

# tests/test_arm_postprocess.py::test_arm_postprocess_ret
irsb = pyvex.IRSB(data=b"\xe9\x1b\xa8\xf0", mem_addr=0xED4028,
                  arch=pyvex.ARCH_ARM_BE_LE, num_inst=1, opt_level=i)
assert irsb.jumpkind == "Ijk_Ret"

e9 1b a8 f0 is the big-endian encoding of 0xe91ba8f0 (ldmdb r11, {r4,r11,sp,pc}). The test passes because instructions are fetched big-endian, which is the opposite of instruction_endness="Iend_LE".

ARCH_ARM_BE is misdeclared in the other direction: PyvexArch("ARM", 32, "Iend_LE") gives it little-endian memory, so it lifts byte-for-byte identically to ARCH_ARM_LE, and its instruction_endness is the inherited "Iend_BE" default while its test feeds it little-endian-encoded bytes.

Neither constant expresses BE8, and taking instruction_endness seriously for ARM breaks both of their tests — I verified this by making pyvex act on it (2 failures out of 64; the same suite is 64/64 green when the BE8 signal is explicit instead). Anyone arriving at this issue and reaching for ARCH_ARM_BE_LE will lose time exactly as I did.

Scope correction: 48 objects, not 662

My earlier comment said 662 big-endian ARM objects. That is the count of big-endian ARM objects, but it is not the affected population. The sweep has since grown to 885 big-endian 32-bit ARM objects, and of those:

• 48 are BE8 (ET_DYN, e_flags = 0x05800400 = EABI5 | BE8 | hard-float). These carry every one of the missed symbols.
• 843 are ordinary BE32 ET_REL objects with EF_ARM_BE8 clear. The sweep scores none of their symbols (relocatable, "addresses are not assigned yet"), so they contributed 0 missed symbols, and scoring them independently shows they are fine: 14,363 sized STT_FUNC symbols, 349 uncovered, 2.4%.

The aggregate share of missed-function instances stands, but it comes from 48 objects, not from an architecture-wide failure. Big-endian ARM in general works; BE8 specifically does not.

What the fix recovers

Prototype across cle (read EF_ARM_BE8), archinfo (express it), pyvex/libVEX (lift it). Both arms run in one environment with a kill switch, so this is not two builds compared to each other.

48 BE8 objects, scored against their own .symtab:

	load errors	sized STT_FUNC symbols	no block covers them	block starts on symbol	blocks	functions
today	0	6863	5873 (85.6%)	853	6292	3823
with BE8	0	6863	1 (0.01%)	6862	154849	53172

The one remaining miss is htab_collisions, an uncalled static whose prologue is ldr r3, [r0, #0x1c] — ordinary under-recovery, not endianness.

Scored instead against the toolchain's own $a/$d mapping symbols, which partition each executable section into code and data with no oracle to trust:

	ARM code bytes marked $a	block bytes landing in $a	in $d	outside any mapping
today	2,089,336	105,794 (5.1%)	2,109	54,335
with BE8	2,089,336	2,026,097 (97.0%)	5,147	29,288

Controls, same environment, change off vs on, comparing arch, block count, function count, nodecode count, symbol count, missed count and error string per object:

• 843 BE32 ARM objects: identical in every field.
• 220 little-endian ARM objects: identical in every field.

That is the property that matters most here — BE32 is the population a BE8 change could plausibly damage, and it is untouched, because the prototype only diverges when EF_ARM_BE8 is set.

Decision 1: where the instruction-fetch endness lives

Both mechanisms work and recover the same code. They are not equivalent.

(a) Pre-swap in pyvex. Hand libVEX a copy of the lift window with each instruction unit byte-reversed. Pure Python, no submodule bump. It is not the two-liner it looks like:

• the buffer angr passes is a zero-copy ffi.from_buffer view of a whole loader segment, so it can be neither swapped in place nor swapped whole — only a window;
• the unit is 4 bytes in ARM and 2 in Thumb, so the swap must know the mode (it can: addr & 1);
• in Thumb the caller's pointer sits one byte past the instruction and libVEX reads guest_code[delta - 1], so the window must start a byte earlier;
• and the one that decides the question: libVEX reads the same bytes two different ways in one lift. Instruction fetch goes through getUShort, which honours guest endness. The Thumb IT-block analysis at guest_arm_toIR.c:19239 reads the 9 preceding halfwords as ((const UShort*)guest_instr)[i] — a native host load that ignores guest endness entirely. One buffer cannot satisfy both.

I measured that last point rather than asserting it. Lifting 8,322 addresses of one object under both mechanisms:

pre-swap variant	lifts differing from the libVEX mechanism
naive window	1447 / 8322
+ 20 bytes of lookback context	5 / 8322
+ that context left unswapped	1 / 8322

Each round of shrinking that number required modelling another of libVEX's internal read conventions, and the last one cannot be removed: the second and later instructions of a Thumb block look back into bytes that the same lift must present swapped for getUShort. The differences are real, not cosmetic — at 0x412c0e the correctly-read halfwords contain 0xbf16, an IT instruction, so the libVEX mechanism emits the ITSTATE guard and the pre-swap arm drops it.

(b) A libVEX instruction-fetch endness. check_hwcaps validates only the ARM architecture level and NEON/VFP3 and ignores unknown bits, so this needs no VexArchInfo field, no cffi change, and no validator change:

/* vex/pub/libvex.h */
#define VEX_HWCAPS_ARM_BE8    (1<<24)

/* vex/priv/guest_arm_toIR.c */
static VexEndness guest_instr_endness;          /* used by getUInt/getUShort */
...
guest_instr_endness = (guest_endness == VexEndnessBE
                       && (archinfo->hwcaps & VEX_HWCAPS_ARM_BE8) != 0)
                      ? VexEndnessLE : guest_endness;

15 added lines in vex, plus 4 in pyvex_c/pyvex.c, because vex_prepare_vai overwrites vai->hwcaps wholesale for ARM and has to preserve this one bit. It costs a vex submodule bump and a native rebuild; it buys an IR generator that knows the truth, no per-lift copy, no Thumb special case, and 64/64 on the pyvex suite.

The decision: pay a vendored-VEX change and a submodule bump for (b), or accept that (a) works by modelling libVEX's private read conventions and will differ from it on Thumb.

Decision 2: how archinfo names BE8

ArchARM.__init__ currently sets instruction_endness to Endness.LE only when endness is LE and leaves the class default (Endness.BE) otherwise, so BE8 cannot be expressed. Three shapes:

1. A be8=True constructor flag on ArchARM (what I prototyped, ~26 lines with arch.py). Smallest, but Arch.__eq__ and __hash__ are (name, bits, memory_endness), so a BE8 arch compares equal to a BE32 one and caches and pickles collide.
2. Distinct classes, ArchARMBE8 / ArchARMHFBE8. Fixes equality; arch_from_id("ARMHF", "be", 32) still returns BE32, so anything reconstructing an arch from a name silently loses the bit.
3. Make instruction_endness authoritative and correct it everywhere. It is currently unmaintained: X86 and AMD64 claim Iend_BE instructions, MIPS32/MIPS64/PPC32/PPC64 claim Iend_BE when little-endian, and AArch64 BE claims Iend_LE (correct, and used by nothing). Correcting it changes a public attribute that pyvex's gymrat lifters branch on, so out-of-tree lifters change behaviour.

Whichever is chosen, these have to move together: Arch.__init__ flips cs_mode, ks_mode and uc_mode to big-endian and byte-reverses ret_instruction, and ArchARM.__init__ swaps in byte-reversed function_prologs/thumb_prologs. All of those are wrong for BE8 and all have to stay little-endian. With them left alone, capstone disassembles a BE8 block correctly and Block.bytes still returns real memory — nothing downstream sees the swapped buffer.

One consumer is already right by accident: cfg_fast.py's ARM UND check byte-swaps its bytes when arch.instruction_endness == Endness.LE, which is exactly what BE8 needs.

cle#610 is not a third option

cle#610 proposes mapping BE8 to ArchARMEL("Iend_LE"), and @mborgerson's review asks whether that should set memory endness. It should, and here is what happens when it does not: all 48 objects fail to load. ELFHashTable.__init__ reads nbuckets with "<" if arch.memory_endness == "Iend_LE" else ">", so a big-endian file read as little-endian gets a byte-swapped bucket count — 28 MemoryError, 18 killed or timed out under a 12 GiB address-space cap and a 600 s limit, 2 raising struct.error: unpack requires a buffer of 470024192 bytes.

Two other things about that patch, for whoever picks it up: it imports from elf_tools.elf.constans.E_FLAGS import EF_ARM_BE8, which is not a module (pyelftools has elftools.elf.constants.E_FLAGS.EF_ARM_BE8 = 0x800000), and its new elif sits after the e_flags & 0x400 hard-float branch, so it never fires on a hard-float BE8 binary — which is all 48 in the sample.

Secondary finding: VFP is broken on any big-endian ARM guest

Independent of BE8, and it caps how good this can get. floatGuestRegOffset in guest_arm_toIR.c is:

if (guest_endness == VexEndnessLE) { if (fregNo & 1) off += 4; }
else { vassert(0); }

so any VFP single-precision access aborts VEX on a big-endian guest. vmov s0, r0 (0xEE000A10) lifts to a 4-byte Ijk_NoDecode stub with Assertion '0' failed in the log. This hits BE32 today and BE8 after the fix, and it matters because every BE8 object in the sample is hard-float. VEX's guest state is host-laid-out, not guest-laid-out, so the little-endian branch looks like it is simply always correct — but that is a call for whoever owns the fork.

Relatedly, the IT-block lookback discussed above reads halfwords natively regardless of guest endness, so it is already wrong for BE32 Thumb on a little-endian host, and it can turn a guarded IT block into an unguarded one.

Reproducing

Any big-endian ARMv7 toolchain: BE8 is the default for big-endian ARMv7, and readelf -h shows Flags: 0x5800400, Version5 EABI, hard-float ABI, BE8. The sample objects are ET_DYN PIEs, EM_ARM, ELFDATA2MSB, e_flags = 0x05800400; four of them by sha256 are f7df7666…, 178e80e1…, 776adfdd…, db24c1f2… (905/756/674/504 sized function symbols, all fully recovered with the change, none recovered without it). Entry-point bytes on all four are 0010a0e1 0200a0e1 07d0cde3 330000ea, which is mov r1, r0; mov r0, r2; bic sp, sp, #7; b … read little-endian and garbage read big-endian.

No pull request, because of the two decisions above. There is also no big-endian ARM ELF in angr/binaries at all — I scanned all 798 ELF files in it: 153 little-endian ARM, zero big-endian ARM — so a regression test needs a fixture added there first.

[zardus]

THIS MESSAGE WAS GENERATED BY AN AUTOMATED PROCESS

Scope update: this is considerably larger than the measurement above, and there
is no public fixture to regress it against.

The earlier comment measured 48 objects, 6,863 symbols and 5,873 missed. A fuller
scan of the same corpus sweep now gives, for the NetBSD earmv7hfeb population
(hard-float ARMv7 big-endian, EF_ARM_BE8 set):

category	missed	of	rate
missed_symbol_function_code	23,972	27,758	86.4%
missed_fde_code	23,972	27,758	86.4%

The two are identical because the symbol table and .eh_frame name the same
function starts on these builds — NetBSD compiles with
-fasynchronous-unwind-tables, so there is one FDE per function at the same
address and length. Two independently derived oracles agreeing to the instance is
corroboration rather than double-counting; on one 3.5 MB object both report
exactly 4,804 of 5,551, and angr has no CFG node, zero-size node, or function at
any of the 4,804.

Worth stating precisely because it is easy to conflate: BE-32 is fine and BE-8
is not. In the same sweep the armeb-v7 relocatable objects score zero in both
categories. The failing population is specifically the one where the linker
byte-swapped the instruction stream and set EF_ARM_BE8, so data is big-endian
while instruction words are stored little-endian — which is the separation this
issue is about.

A sample from that population, for the record:

e_ident  7f 45 4c 46 01 02 01 00      EI_CLASS=1, EI_DATA=2 (MSB)
e_type   ET_DYN   e_machine EM_ARM    e_flags 0x05800400
         = EABI v5 | EF_ARM_BE8 (0x00800000) | EF_ARM_ABI_FLOAT_HARD (0x400)

archinfo/arch_arm.py sets instruction_endness only on the little-endian
branch, so a big-endian ArchARMHF inherits the Arch default and the lifter
reads instruction words in the wrong order. Nothing in angr, cle or archinfo
reads EF_ARM_BE8 — a code search for BE8 in archinfo and cle at master
returns nothing today.

The part that needs a decision from someone other than me: there is no BE-8
fixture in angr/binaries. All 155 ARM ELFs there are little-endian and none has
EF_ARM_BE8, so whatever shape the fix takes, it cannot be regression-tested
publicly until such a fixture is added. I am happy to prepare one if that is
wanted; I did not want to add a binary to that repository unasked.

I am not asking for the design question here to be reopened — the two decisions
this is blocked on are yours. This is only to say the population behind them is
about four times what the earlier comment measured.