Raspberry Pi Pico: What is this code doing in its boot ROM, line 442?
github.com
github.com
06: 00 B5 push {lr}
08: 42 40 eors r2, r0
0a: 00 2A cmp r2, #0
0c: 00 F0 02 F8 bl #0x14
14: 70 46 mov r0, lr
16: 00 47 bx r0
None of the previous three instructions modifies the flags. (I checked in the ARM reference manual.) Thus, “BHS” (branch unsigned higher or same) uses the flags from the “CMP R2,#0” above. _Every_ value of R2 is higher (in the unsigned sense) or same as 0. Hence, the following branch is always taken:
10: F6 D2 bhs #0
00: 11 38 subs r0, #0x11
02: C0 7A ldrb r0, [r0, #0xb]
04: 00 BD pop {pc}
0x2A is 42 (decimal)! Could this be an Easter egg; a very obfuscated way of returning 42, the Answer to the Ultimate Question of Life, the Universe, and Everything? (Remember that the Raspberry design team is from Britain, same as Douglas Adams.)
A very pleasing coincidence!
* https://developer.arm.com/documentation/ddi0210/c/Introducti...
It does indeed return 42
Also returns 42.
And Eben studied at St John's College, Cambridge, same as Douglas Adams
After the addition of double-precision floating point support in V2 of the boot ROM (B1 silicon), we had just over 30 bytes spare. Removing any of the slightly obtuse space-saving techniques already used in the code always resulted in code that didn't fit, so we were left with the free space.
Nature abhors a vacuum, so I decided on an Easter Egg (note there is no secure code in the RP2040 boot ROM). It was surprisingly challenging to come up with some very short code which actually did something, but whose purpose was not immediately obvious. I was also super interested to see how long it would take someone to find it - 15 months apparently :-)
Hopefully it provided you some amusement/puzzle value... I sort of hoped it would be more confusing the more ARM assembly you knew, as it potentially sets off all sorts of wrong pattern-matching in the brain.
00: 11 38 subs r0, #0x11
02: C0 7A ldrb r0, [r0, #0xb]
04: 00 BD pop {pc}
06: 00 B5 push {lr}
08: 42 40 eors r2, r0
0a: 00 2A cmp r2, #0
0c: 00 F0 02 F8 bl #0x14
10: F6 D2 bhs #0
12: 8E 46 mov lr, r1
14: 70 46 mov r0, lr
16: 00 47 bx r0
Edit2: I take that back - it's just very "creatively" written.
04 pop {pc} -> this is an odd way to return from a function on ARM, and likely means that these first bytes would be a very odd function.
06 push {lr} -> OK, maybe a valid prologue, but this function ignores the result of the cmp and calls 0x14.
> I'd expect bx lr here
LR is being clobbered by the bl (EDIT: bl, not blx)
Well yeah, that's what I said above.
> LR is being clobbered by the blx
There's no blx in the first section. These first six bytes would only make sense if this small stub ended in bx lr, therefore I don't think it's a valid function.
"bx lr" is only used on it's own when the function doesn't call another function (altering lr), and doesn't need to save any registers.
If you see pop {lr}; bx lr then that's code that's being compiled to explicitly support Armv4 (e.g. Arm7TDMI)
06: 00 B5 push {lr}
// r0 = arg1, r1 = arg2, r2 = arg3
if (arg3 ^ arg1 >= 0u)
return 42; // edited //*(u8 *)(r0 - 17 + 11);
else // dead code (edited)
return arg2();> The `BL` instruction does not change the flags.
Doesn't seem like much of an assumption to me :P
"Why No Easter Eggs"
https://docs.microsoft.com/en-us/archive/blogs/larryosterman...
https://hn.algolia.com/?query=Why%20no%20Easter%20Eggs
... and
Cute, condescending error messages are unprofessional and unhelpful. If fewer programs were steaming piles of garbage I might feel differently about it.
The idea that Easter Eggs are security risks comes across as the most pedantic paranoid position. Statistically speaking software is not failing because of Easter eggs.
This does not seem to be about security but about typical American style “cover your ass” legalize thinking.
Sure if you create a space rocket control system I would not put in an Easter egg. But if it is a code editor, word processor, email reading client etc then who cares? Nobody will die and million dollar equipment is not going to blow up.
Disclaimer: I have never made an Easter Egg and I get that companies don’t do it if it causes problems with customers. I just think customers who complain about this should get a life.
https://github.com/raspberrypi/pico-bootrom/blob/ef22cd8ede5...
(@dang, worth updating the link?)
But it also is just poor for code. I think it wants to find full words, so searching for substrings generally results in too few matches. That's made worse by its special character handling in word splitting and query parsing which makes some text impossible to find.
EDIT: I spoke too quickly, looking at the disassembly in the sibling comment.
EDIT 2: That disassembly looks like data, TBH.
In this case, the use is documented where it's implemented: https://github.com/raspberrypi/pico-bootrom/blob/master/boot... . It's a custom wrapper to call ROM functions. When the ROM function returns, the trampoline executes a debugger breakpoint. This is done so that the debugger can call into ROM easily without needing to set a hardware breakpoint.
https://datasheets.raspberrypi.com/rp2040/rp2040-datasheet.p...
"A 16kB read-only memory (ROM) is at address 0x00000000. The ROM contents are fixed at the time the silicon is manufactured."
But the "Easter egg" function discussed in this HN thread is not inside any code loaded/executed from flash. It is inside the boot ROM (as I've repeatedly stated); and that is indeed read-only memory, i.e., it cannot be modified except by manufacturing a new chip revision.
It's probably an Easter egg or an undocumented workaround for something.