/* Note true(1) will return EXIT_FAILURE in the
edge case where writes fail with GNU specific options. */
13
11
154
Conversation
You’re unable to view this Tweet because this account owner limits who can view their Tweets. Learn more
If you don't allow it to fulfill its purpose by disallowing exit_group and exit system calls using seccomp-bpf, it resorts to killing itself with a segmentation fault. If you stop it from doing that too, it has to loop forever in eternal shame.
sourceware.org/git/?p=glibc.g
1
5
It is architecture-dependent but the “killing itself” part is cleaner than I expected (and than this tweet implied): sourceware.org/git/?p=glibc.g
1
Most architectures use some kind of fatal breakpoint instructions. Some of them manually trigger an illegal instruction. It varies whether you get SIGILL or SIGSEGV. It doesn't necessarily work due to signal handling or debuggers. If compiler has __builtin_trap it uses that.
1
It doesn't know how to do anything other than looping on 32-bit ARM if the compiler doesn't have __builtin_trap which is why I know it has that loop. It just helplessly loops forever if you didn't allow it to call exit/exit_group or the breakpoint instruction somehow failed.