ARM Assembly: ∞ Ways to Return (2017) • Hacker News Board

Re: ARM Assembly: ∞ Ways to Return (2017)

#11

Post by Olipro » Fri, Feb 10, 2023, 8:11 PM UTC

For older architectures, you really want to use the BX instruction unless you can guarantee you're not switching execution mode.

as a bit of pointless trivia, MOV PC, PC does not cause an infinite loop - it skips the instruction immediately following.

Re: ARM Assembly: ∞ Ways to Return (2017)

#12

Post by pm215 » Fri, Feb 10, 2023, 8:28 PM UTC

benj111 wrote: post #6

Dwedit wrote: post #5

Method 1 (popping PC off the stack) and Method 3 (mov pc,lr) do not work on the earliest ARM processors that support THUMB, as it will not switch to THUMB mode without executing a BX instruction. Checking reference manuals: ARMV4T (ARM7TDMI/ARM9TDMI): Does NOT switch to THUMB mode automatically ARMV5: Does NOT switch to THUMB mode automatically ARMV7: Does switch to THUMB mode automatically

I thought it switched to thumb based on odd/ evenness. Plus if you don't want to switch to thumb, this still works?

It is based on whether the low bit of the jump target is 0 or 1, but the first version of Thumb only did that check-and-switch-mode on a small set of jump instructions, not on every way you could alter the program counter. For the others you got the same behaviour you always had for an attempt to jump to an unaligned address, which is to say the low bit was just ignored. The compiler had to generate slightly different code if you wanted your function to support interworking. In the versions of Thumb starting with IIRC Armv5t or maybe v6t2, more instructions did the mode switch check, and codegen got a bit simpler.

Re: ARM Assembly: ∞ Ways to Return (2017)

#13

Post by not2b » Fri, Feb 10, 2023, 8:44 PM UTC

As other commenters have mentioned, exploiting this will confuse other tools and debuggers. Also it tends to play havoc with branch prediction meaning that there may be performance penalties.

Re: ARM Assembly: ∞ Ways to Return (2017)

#14

Post by crest » Fri, Feb 10, 2023, 9:23 PM UTC

klodolph wrote: post #4

Thankfully, PC is no longer a GPR in ARM64. Making PC a GPR seems elegant at first glance, but when you actually dive into it and see how it affects processor implementations and how it affects the code you write, it turns out to be extremely messy and inconvenient. Good riddance PC as GPR, don’t let the door hit you on the way out.

It's neat when writing assembler e.g. add a scaled byte value to the PC to implement a jump table or perform a scaled and indexed load to the PC. In ARM it also produced a neat short and fast function prologue/epilogue. In my opinion the worst problem causes are the 1001 and one special cases it adds in an optimised out of order implementation. The Thumb interworking makes it more worse, but is useful to increase code density in ARM v6-M and can even increase performance (per clock) of ARM v7-M cores. I don't expect it causes too much problems in single-issue in-order implementations like the Cortex M3 and M4. I would like to know how much design time and core area is spend on this in the M7 and M85 cores.

Re: ARM Assembly: ∞ Ways to Return (2017)

#15

Post by flykespice » Fri, Feb 10, 2023, 10:18 PM UTC

wk_end wrote: post #3

garbagecoder wrote: post #2

fwiw, if you're using ARM assembly on an Apple device there are a few differences and one of them is how you pass arguments. https://developer.apple.com/documentation/xcode/writing-arm6...

The article is describing classic ARM. (Modern) Apple devices are all ARM64, which doesn't have the PC as a GPR. The article is also entirely about how the PC is a general-purpose register on 32-bit ARM machines. No idea if the 1st gen iPhones or whatever used an idiosyncratic calling convention...but it's moot in the context of this post, because argument passing isn't covered here! This post really is just about th…

The only one getting mad here is you for no reason.

Re: ARM Assembly: ∞ Ways to Return (2017)

#16

Post by [deleted] » Sat, Feb 11, 2023, 12:04 AM UTC

Dwedit wrote: post #7

benj111 wrote: post #6

Earlier quoted context omitted.

I thought it switched to thumb based on odd/ evenness. Plus if you don't want to switch to thumb, this still works?

It does work if you intend to stay in ARM mode only, and will crash if THUMB-mode code calls the function. ARMV7 will do the mode switch automatically and not crash.

[deleted]

Re: ARM Assembly: ∞ Ways to Return (2017)

#17

Post by Dwedit » Sat, Feb 11, 2023, 12:32 AM UTC

Olipro wrote: post #11

For older architectures, you really want to use the BX instruction unless you can guarantee you're not switching execution mode. as a bit of pointless trivia, MOV PC, PC does not cause an infinite loop - it skips the instruction immediately following.

Correct, PC as a source register means PC + 8.

Re: ARM Assembly: ∞ Ways to Return (2017)

#18

Post by schoen » Sat, Feb 11, 2023, 2:55 AM UTC

It's sad (but very reasonable) that newer architectures have tried to be significantly less flexible about control flow for security reasons, in the direction of "there is only one way to call a function, and only one way to return from a function, and you have to tell the system where your functions and returns are so that someone can't call or return into the middle or can't leave the function at an unexpected point" (and, of course, no self-modifying code, and even discouraging JITs).

Re: ARM Assembly: ∞ Ways to Return (2017)

#19

Post by sweetjuly » Sat, Feb 11, 2023, 3:03 AM UTC

crest wrote: post #14

klodolph wrote: post #4

Thankfully, PC is no longer a GPR in ARM64. Making PC a GPR seems elegant at first glance, but when you actually dive into it and see how it affects processor implementations and how it affects the code you write, it turns out to be extremely messy and inconvenient. Good riddance PC as GPR, don’t let the door hit you on the way out.

It's neat when writing assembler e.g. add a scaled byte value to the PC to implement a jump table or perform a scaled and indexed load to the PC. In ARM it also produced a neat short and fast function prologue/epilogue. In my opinion the worst problem causes are the 1001 and one special cases it adds in an optimised out of order implementation. The Thumb interworking makes it more worse, but is useful to increase cod…

Even for regular in-order cores, it makes branch prediction a massive pain because now your fast frontend predictors need to essentially fully decode the instruction in order to determine if it can be considered a branch. Most other ISAs make this simple because there are only a few opcodes that change control flow and so you can very easily just stuff that in your early frontend decoder.

RISCV unfortunately didn't quite do this well since return uses the same opcode for call, return, and indirect branch and so you have to fully decode the instruction in order to determine whether you should use the RAS or your other predictors. This isn't a problem that can't be overcome (next line predictors help a lot for these early predictions) but it makes something very performance critical just that much harder.

Re: ARM Assembly: ∞ Ways to Return (2017)

#20

Post by vore » Sat, Feb 11, 2023, 3:13 AM UTC

benj111 wrote: post #6

Dwedit wrote: post #5

Method 1 (popping PC off the stack) and Method 3 (mov pc,lr) do not work on the earliest ARM processors that support THUMB, as it will not switch to THUMB mode without executing a BX instruction. Checking reference manuals: ARMV4T (ARM7TDMI/ARM9TDMI): Does NOT switch to THUMB mode automatically ARMV5: Does NOT switch to THUMB mode automatically ARMV7: Does switch to THUMB mode automatically

I thought it switched to thumb based on odd/ evenness. Plus if you don't want to switch to thumb, this still works?

On older ARM only bx is allowed to switch Thumb state, even if the address you're giving it is e.g. a Thumb address in ARM mode. You can still use pc as a GPR to jump ARM-ARM or Thumb-Thumb, though.