Linux (Kernel) and BSD Leftovers
-
LWN ☛ Pitchforks for RDSEED
RDRAND is recommended for most uses; it is faster and can significantly stretch the amount of entropy that is available to the system. Within the kernel, RDSEED is used to seed the kernel's random-number generator, but for little else. An important point to note is that neither of these instructions is privileged; they are equally available to user-space code. Also important is the fact that either instruction can fail if there is not sufficient entropy available. (See this page for lots of details on how these instructions work).
On the x86 architecture, the kernel has a pair of functions, rdseed_long() and rdrand_long(), that make use of the above instructions. Kirill Shutemov recently observed that, while rdrand_long() will retry ten times if RDRAND fails, rdseed_long() gives up immediately. He posted a patch adding a retry loop to rdseed_long(), and another to issue a warning if even ten tries were not enough to get a successful result. That is where the discussion began.
-
LWN ☛ A look at dynamic linking
When the Linux kernel is asked to execute a program, it looks at the start of the file to determine what kind of program it is. The kernel then consults both its built-in rules for shell scripts and native binaries and the binfmt_misc settings (a feature of the kernel allowing users to register custom program interpreters) to determine how to handle the program. A file beginning with "#!" is identified as the input of the interpreter named on the rest of the line. This faculty is what lets the kernel appear to execute shell scripts directly — in reality executing an interpreter and passing the script as an argument. A file starting with "\x7fELF", on the other hand, is recognized an an ELF file. The kernel first looks to see whether the file contains a PT_INTERP element in the program header. When present, this element indicates that the program is dynamically linked.
The PT_INTERP element also specifies which dynamic linker the program expects to be linked by — also called the interpreter, confusingly. On Linux, the dynamic linker is usually stored at an architecture-specific path such as /lib64/ld-linux-x86-64.so.2. It is not allowed to itself be dynamically linked, to avoid an infinite regress. Once the dynamic linker has been found, the kernel sets up an initial address space for it in the same fashion as any other statically linked executable and gives it an open file descriptor pointing to the program to be executed.
-
DragonFly BSD Digest ☛ In-kernel WireGuard on DragonFly available now
Aaron LI’s written up a nice summary of what’s been added to support WireGuard on DragonFly and how to get started. You need to be on -master to use it, but if you want to read about it there’s always the man page.
-
Undeadly ☛ New code for SIGILL faults help identify misbranches
The OpenBSD compiler will insert an extra instruction in all the places where a branch is supposed to land, and if it lands anywhere else, a CPU fault is raised and your program gets an "Illegal Instruction".