[HN Gopher] History of Null Pointer Dereferences on macOS
___________________________________________________________________
History of Null Pointer Dereferences on macOS
Author : voxadam
Score : 79 points
Date : 2025-03-17 13:11 UTC (4 days ago)
(HTM) web link (afine.com)
(TXT) w3m dump (afine.com)
| LoganDark wrote:
| Hugged to death?
|
| Edit: Seems good half an hour later!
| gsf_emergency_2 wrote:
| https://archive.ph/p86V1
| usrnm wrote:
| How large is the protected memory area? In my experience it's
| often not zero but some offset from zero that is accessed
| TazeTSchnitzel wrote:
| 4GiB
| pjmlp wrote:
| Thanks to the wonders of UB, the sample on the article when
| compiled with optimization on, it actually reduces to,
| //clang -o null_dereference null_dereference.c #include
| <stdio.h> int main() { int *ptr = NULL; //
| Initialize a pointer to NULL int value = *ptr; //
| Attempt to dereference the NULL pointer
| printf("Value: %d\n", value); // This line will reached, because
| the previous will be optimized away. return 0;
| }
|
| Example, https://godbolt.org/z/Kv3rcz1ch
| pajko wrote:
| What do you mean? There is nothing optimized away. If there
| would be an if statement to check for a NULL pointer, yes, that
| most likely would be optimized away due to UB (if something is
| undefined, it is not NULL, so the check can be removed...). To
| make it implementation defined, the -fno-delete-null-pointer-
| checks parameter can be used:
| https://news.ycombinator.com/item?id=39463804
| DonHopkins wrote:
| How things change! Page zero was extremely important on the Apple
| ][.
| nomad41 wrote:
| Very interesting. Can you expand on why? Or point to some
| relevant sources. Thank you in advance.
| 0x0 wrote:
| Probably because the 6502 CPU had instructions for optimized
| access to the zero page (first 256 bytes of RAM), this would
| also apply to C64 and NES etc. If you want to use "Indirect
| Indexed" memory accesses then I think it also has to go
| through an address held in the zero page.
|
| See https://www.nesdev.org/obelisk-6502-guide/addressing.html
| pajko wrote:
| The AVR architecture puts its registers starting from
| address 0 of its data memory. As a twist, the program
| memory also starts at 0 (due to the Harvard architecture).
| jisnsm wrote:
| > A NULL pointer dereference occurs when software attempts to
| access memory at address 0 (the NULL address) via a pointer set
| to NULL.
|
| There is nothing in the standard that says that NULL must be 0.
| derefr wrote:
| On a tangent re: memory safety in operating systems --
|
| We hear a lot these days from the (very much in-the-open) debate
| over how much (if any) of the Linux kernel should be rewritten in
| Rust for memory safety.
|
| But does anyone know if a similar debate is also going on inside
| Apple re: XNU/Darwin, or within Microsoft re: NTOS? (Maybe not
| using Rust in particular, but some other memory-safe systems
| language?)
| jeroenhd wrote:
| Microsoft is hard at work rewriting risky C code into Rust (old
| presentation mentioned here:
| https://www.bleepingcomputer.com/news/microsoft/new-
| windows-...). They're also actively working on things like
| their Rust framework for Windows drivers.
|
| I don't know about Apple. I'd expect them to go for Swift
| rather than Rust, but Darwin doesn't seem to include any such
| code yet.
|
| Linux is full of C developers who don't want anything to do
| with Rust actively working against the current Rust for Linux
| experiment. I expect Linux to end up lagging behind Apple and
| Microsoft in this area because of the difference in
| organisational structure and priorities.
| mrpippy wrote:
| On macOS x86_64, the size of PAGEZERO cannot be set to 0, but it
| can be set to 0x1000 (4 KiB) instead of the default 4 GiB. Wine
| does this to support running Windows EXEs which need to load at a
| fixed address.
|
| On ARM64, PAGEZERO's size cannot be made smaller than 4 GiB.
___________________________________________________________________
(page generated 2025-03-21 23:02 UTC)