social.noyu.me

did you know that there are Android phones with 64-bit CPUs and 64-bit kernels but which will only run 32-bit apps? did you know they are actually very common, still manufactured in 2024 by major brands, and the bane of Android console emulator developers everywhere? it sucks.

‪the reason for this is memory consumption. on Android, all apps are forked from the zygote, a process that is always running and has a preloaded set of libraries (libc, graphics drivers, presumably also Android Runtime, etc). but to support 64-bit and 32-bit apps you need two.‬

‪so… if you have a phone with a 64-bit CPU (every modern Android phone) and a 64-bit kernel (probably also every modern Android phone), but less than 4GB RAM… supporting both 32-bit and 64-bit applications is kind of painful memory-wise, so they just… use a 32-bit only userland‬

‪now i can see how they came to that, but it's an extremely Google Moment honestly. Apple didn't want to play this game and gave 32-bit a sudden, swift, merciful death. Google are prolonging the agony for everyone. I can't stress enough how absurd “32-bit-only 64-bit device” is‬

@hikari if i understand it correctly, apple also plays a similar game on the watches. They do run aarch64, but with 32 bit pointers. Though this is most likely irrelevant for emulator devs. :P

@hikari agree, but still annoying if you decided to use swift for some reason and care about your app size (lol who does that in $CURRENT_YEAR). Can't share libraries with the main app, since that's a different arch.

@hikari @Kahanis With what, userspace PAE?

@saagar @Kahanis @hikari are these 32-bit-only Android devices still using the armv7 instruction set? arm64_32 at least lets you still use all thirty-one 64-bit GPRs

@joe @Kahanis @hikari PC is a GPR if you try hard enough

@saagar @Kahanis @joe @hikari that’s right

@saagar @joe @Kahanis @hikari PC is not addressable on arm64. It can only be indirectly modified, unlike arm32 that can use it as the source or destination of most instructions.

@shac @joe @Kahanis @hikari Guess 64-bit doesn’t really let you take full advantage of the hardware after all

@saagar @Kahanis @shac @hikari but the biggest crime aarch64 committed was taking away conditional everything

@joe @Kahanis @shac @hikari What about conditional conditions

@saagar @Kahanis @shac @hikari what if you use a thumb IT instruction over conditionalized ARM instructions

@joe @saagar @Kahanis @hikari An architecture where any instruction can be a conditional branch is objectively insane. But also the most fun assembly to write.

@shac @joe @Kahanis @hikari That’s every architecture that supports breakpoints

@shac @Kahanis @hikari @joe The extra-fun architectures are where you can branch halfway through an instruction

@saagar @Kahanis @joe @shac @hikari tryna watchpoint a CPY?

@siguza @Kahanis @joe @shac @hikari This is actually one of the things I think ARM is completely out of their depth on, x86 actually thinks about what happens in situations like these and for a lot of traps ARM goes “why don’t you figure out how to reconstruct state ¯\_(ツ)_/¯”

@saagar @Kahanis @joe @shac @hikari which is actually a more sane thing to present to software, just abysmal to figure out how to do... while x86 looks at all the options, picks the worst one, and then everyone is stuck with that forever.

@saagar huh, does ARMv8 (or later) have non-restartable instructions? Is this like vector stuff or something? I thought it was pretty clean in this regard in that you can always just ERET back after resolving the fault and the program will keep going.

Or, hmm, maybe things like non-FPAC IABORTs are non-restartable since PC is trashed and you can't (confidently) know if it's PAC or just a bogus address? Though if you're trying to recover from a PAC fail you kinda deserve it.

@ezhes_ Not sure, this was mostly a watchpoint hate session (which you may have seen a previous iteration of: https://federated.saagarjha.com/notice/ATdDMNXtw4QuTBZ1jU)

@saagar in theory, doesn't FEAT_Debugv8p2 solve this whole mess? ESR.ISS.WPT reports the matched watchpoint number for a trap and is mandatory. Though, they kinda ruin it with WPTV which can make WPT invalid, but that goes away in 8p9 where WPT cannot be invalid.

https://arm.jonpalmisc.com/2023_09_sysreg/AArch64-esr_el2#fieldset_0-24_0_24-23_18-1

@ezhes_ > Watchpoint might be false-positive.

lol

@saagar @Kahanis @joe @shac @hikari i can't find it now but i saw someone post a month or two ago a snippet that used the fact an instruction would mutate register state before faulting to tell if a page wasn't resident in memory and the kernel was reattempting it after a fault 🙂

@sickeningsprawl @saagar @Kahanis @joe @shac @hikari illegalize this

@sickeningsprawl @Kahanis @joe @shac @hikari https://infosec.exchange/@jann/112983458910799814

@saagar @Kahanis @joe @shac @hikari yes thank you 🙏

@shac @saagar @Kahanis @hikari it would've been nice to keep conditional calls in arm64 at least, there are some nice things you can do with them