7 ms·

This was only 'enforced' by the linker on x86. You could handcraft a Mach-O executable to get around it. But it is now enforced enforced by OSX on ARM. I don't

This was only 'enforced' by the linker on x86. You could handcraft a Mach-O executable to get around it. But it is now enforced enforced by OSX on ARM. I don't see any good reason for this. My own half assed explanation is they're enforcing 32b cleanliness. It's not a very good explanation. But it's my explanation for something I don't like.

worewood 4y ago
When migrating 32bit apps to 64bit platforms, it's common to follow the recipe: 1. Try to recompile on 64bit without any changes 2. Realize the program does not work because the types have different sizes now 3. Cast everything on sight to types that have same size as in 32bit. 4. Now the program "works" (as in, it compiled and maybe ran but you didn't test thoroughly) This address space restrictions ensures that if you happen to cast a pointer in this way it will not work, forcing the developer to review what he's doing.
- CalChris 4y ago
  This argument is similar to my enforcing 32b cleanliness. Really, that was an issue back in the 90s. But this enforcement happened with the x86_64 to ARMv8 migration, 64b to 64b. So I would like an explanation from Apple for why this now. What is their rationale?
  - DHowett 4y ago
    The first iPhones were AArch32, and there was likely a sizable contingent of iOS software that was written to target the only existing bitness at the time :) The same reasons GP offered still apply there. The amount of software directly ported from x86_64 to AArch64 was probably minimal.
- gruez 4y ago
  >3. Cast everything on sight to types that have same size as in 32bit. Which is why on windows they defaulted to 32 bits for ints
  - WalterBright 4y ago
    Except for 16 bit Windows!
- WalterBright 4y ago
  > 2. Realize the program does not work because the types have different sizes now Such an enormous amount of time in C/C++ programming is devoted to accounting for the size of an int, long, wchar_t, and long long being unreliable when porting. This is why D has int fixed at 32 bits, long fixed at 64 bits. It's amazing how the problems just melt away. Now, just remember to use size_t for everything used as an index, and you're good to go. (ptrdiff_t is almost never needed.)
  - yardstick 4y ago
    Isn’t it similar in C with using uint16_t, uint32_t, etc? IMO it helps to write programs from the ground up that you know will need to be cross compiled.
    - WalterBright 4y ago
      Yes, you could use int32_t. But who wants to type that? People default to convenience, and that's int. Besides, the C Standard Library doesn't even use stdint.h. Now you've got unknown implicit integer conversions going on. It's just not a solution.
mrpippy 4y ago
You didn’t need to handcraft it, the linker has a ‘pagezero_size’ argument which allows you to set it as small as one page and then the rest of the low 4GB can be used.
- CalChris 4y ago
  I remember trying this repeatedly with various incantations but always getting: segaddr blah conflicts with pagezero_size Maybe there was an incantation I didn't find. But I did handcraft it and then Apple cancelled even that. Now we're gonna have to deal with a 4GB zero page. Period.
  - p_l 4y ago
    That's going to make certain old optimizations broken, I guess. But I hope to avoid arm64 macs (kinda campaigning to get linux machines at work) so it may remain only theoretical.
ridiculous_fish 4y ago
Can't one just remap the zero page?
- CalChris 4y ago
  No, you cannot. You can't remap it and you can't resize it. This is part of design assumptions baked into a couple of newish Apple technologies, ASLR and Address Signing.
TazeTSchnitzel 4y ago
Maybe they're now relying on it for safety in core system libraries that get linked into your process? If you can be sure that the offset in *(ptr + offset) is always a 32-bit unsigned type, you get null pointer checking for free, right?

worewood 4y ago

When migrating 32bit apps to 64bit platforms, it's common to follow the recipe: 1. Try to recompile on 64bit without any changes 2. Realize the program does not work because the types have different sizes now 3. Cast everything on sight to types that have same size as in 32bit. 4. Now the program "works" (as in, it compiled and maybe ran but you didn't test thoroughly) This address space restrictions ensures that if you happen to cast a pointer in this way it will not work, forcing the developer to review what he's doing.

CalChris 4y ago
This argument is similar to my enforcing 32b cleanliness. Really, that was an issue back in the 90s. But this enforcement happened with the x86_64 to ARMv8 migration, 64b to 64b. So I would like an explanation from Apple for why this now. What is their rationale?
- DHowett 4y ago
  The first iPhones were AArch32, and there was likely a sizable contingent of iOS software that was written to target the only existing bitness at the time :) The same reasons GP offered still apply there. The amount of software directly ported from x86_64 to AArch64 was probably minimal.
gruez 4y ago
>3. Cast everything on sight to types that have same size as in 32bit. Which is why on windows they defaulted to 32 bits for ints
- WalterBright 4y ago
  Except for 16 bit Windows!
WalterBright 4y ago
> 2. Realize the program does not work because the types have different sizes now Such an enormous amount of time in C/C++ programming is devoted to accounting for the size of an int, long, wchar_t, and long long being unreliable when porting. This is why D has int fixed at 32 bits, long fixed at 64 bits. It's amazing how the problems just melt away. Now, just remember to use size_t for everything used as an index, and you're good to go. (ptrdiff_t is almost never needed.)
- yardstick 4y ago
  Isn’t it similar in C with using uint16_t, uint32_t, etc? IMO it helps to write programs from the ground up that you know will need to be cross compiled.
  - WalterBright 4y ago
    Yes, you could use int32_t. But who wants to type that? People default to convenience, and that's int. Besides, the C Standard Library doesn't even use stdint.h. Now you've got unknown implicit integer conversions going on. It's just not a solution.

mrpippy 4y ago

You didn’t need to handcraft it, the linker has a ‘pagezero_size’ argument which allows you to set it as small as one page and then the rest of the low 4GB can be used.

CalChris 4y ago
I remember trying this repeatedly with various incantations but always getting: segaddr blah conflicts with pagezero_size Maybe there was an incantation I didn't find. But I did handcraft it and then Apple cancelled even that. Now we're gonna have to deal with a 4GB zero page. Period.
- p_l 4y ago
  That's going to make certain old optimizations broken, I guess. But I hope to avoid arm64 macs (kinda campaigning to get linux machines at work) so it may remain only theoretical.

ridiculous_fish 4y ago

Can't one just remap the zero page?

CalChris 4y ago
No, you cannot. You can't remap it and you can't resize it. This is part of design assumptions baked into a couple of newish Apple technologies, ASLR and Address Signing.

TazeTSchnitzel 4y ago

Maybe they're now relying on it for safety in core system libraries that get linked into your process? If you can be sure that the offset in *(ptr + offset) is always a 32-bit unsigned type, you get null pointer checking for free, right?