ryanpetrich

aligned_alloc is a C function. It doesn't help the compiler prove that two pointers can't alias. restrict is the keyword that does.

This is to suppress a compiler warning that the k_sz argument is unused.

The bigger problem is mutability. Any pointers into the bit-packed enum storage become invalid as soon as you change its type. To solve this you can either prohibit pointers into bit-packed enum storage, which is very limiting, or introduce immutability into the language. Immutability is particularly difficult to add to go, where default zero-values emerge in unexpected places (such as the spare capacity of slices and the default state of named return values)

Memory barriers don't force a flush of all CPU cache. They will enforce the ordering of memory operations issued before and after the barrier instruction, preserving the contents of the CPU's various caches.

Yes, that's right. You need to update the entire OS for a minor security fix to iMessage.

Thanks for writing this. It takes a deep understanding to explain such complicated concepts in an accessible way. Reading it brought back fond memories of hacking on jailbreak projects deep into the night.

Go's internal linker is much faster than the system linker thanks to some go-specific optimizations. Go must fall back to the system linker whenever CGO is used.

If best effort is good enough and your use case doesn't require robustness, reading out of host /proc certainly works. Tracking execs with hooks in the kernel's internal exec mechanism with a separate indexing step at startup is worth the extra effort for use cases that do require accurate data, such as security observability.

It's not robust at all. Programs can and will exit before the userspace daemon is able to read from /proc. Malicious programs can even attribute their network activity to any program on the system they are able to exec by execing that program immediately afterwards or concurrently from another thread. One can properly track program paths/arguments by setting kprobes on the exec functions within the kernel and copying the data to a ring buffer read in userspace or by reading out of the task struct using bpf_probe_read_kernel.

This is what ETags are for. Upon a user's first visit the server should return an ETag uniquely representing the current version of the page. The browser will cache both the page and the tag. Upon subsequent page visits the browser will send an If-None-Match header containing the tag for the version of the page it has cached. The server should compare the incoming tag with the tag for the current version and return a "304 Not Modified" response if the tags match or a full response with the newer tag in the ETag header if they don't.

A benefit of storing the reference count in the high bits is that overflows will never corrupt the flag bits and can be detected using the processor's flags instead of requiring a separate check. I'm not sure if this property is used here.

Apple's recent aarch64 implementations don't support any of the 32 bit ARM instruction sets, and aarch64 is a significant departure from armv7