Adventures in Code Land

Today I was looking up René Rebe's livestream last night on the madness of the way we develop software like it's still the '70s. He was talking about kernel/desktop developer community interactions, I think. I need to look again, ... but I looked up his home page https://rene.rebe.de/about/ and found is other channel, There I found this:

It's about how the FSF handled https://nvd.nist.gov/vuln/detail/CVE-2023-4911 (Posted October 3, last updated November 6, 2023): from https://packetstormsecurity.com/files/174986/glibc-ld.so-Local-Privilege-Escalation.html:

The GNU C Library's dynamic loader "find[s] and load[s] the shared
objects (shared libraries) needed by a program, prepare[s] the program
to run, and then run[s] it" (man ld.so). The dynamic loader is extremely
security sensitive, because its code runs with elevated privileges when
a local user executes a set-user-ID program, a set-group-ID program, or
a program with capabilities. Historically, the processing of environment
variables such as LD_PRELOAD, LD_AUDIT, and LD_LIBRARY_PATH has been a
fertile source of vulnerabilities in the dynamic loader.

Recently, we discovered a vulnerability (a buffer overflow) in the
dynamic loader's processing of the GLIBC_TUNABLES environment variable
(https://www.gnu.org/software/libc/manual/html_node/Tunables.html). This
vulnerability was introduced in April 2021 (glibc 2.34) by commit 2ed18c
("Fix SXID_ERASE behavior in setuid programs (BZ #27471)").

We successfully exploited this vulnerability and obtained full root
privileges on the default installations of Fedora 37 and 38, Ubuntu
22.04 and 23.04, Debian 12 and 13; other distributions are probably also
vulnerable and exploitable (one notable exception is Alpine Linux, which
uses musl libc, not the glibc). We will not publish our exploit for now;
however, this buffer overflow is easily exploitable (by transforming it
into a data-only attack), and other researchers might publish working
exploits shortly after this coordinated disclosure.

This is about GLIBC Tunables:

Tunables are a feature in the GNU C Library that allows application authors and distribution maintainers to alter the runtime library behavior to match their workload. These are implemented as a set of switches that may be modified in different ways. The current default method to do this is via the GLIBC_TUNABLES environment variable by setting it to a string of colon-separated name=value pairs. For example, the following example enables malloc checking and sets the malloc trim threshold to 128 bytes:

GLIBC_TUNABLES=glibc.malloc.trim_threshold=128:glibc.malloc.check=3
export GLIBC_TUNABLES

Tunables are not part of the GNU C Library stable ABI, and they are subject to change or removal across releases. Additionally, the method to modify tunable values may change between releases and across distributions. It is possible to implement multiple ‘frontends’ for the tunables allowing distributions to choose their preferred method at build time.

Finally, the set of tunables available may vary between distributions as the tunables feature allows distributions to add their own tunables under their own namespace.

See 38.3 Dynamic Linking Tunables:

Dynamic linker audit modules are loaded in their own dynamic link namespaces, but they are not accounted for in glibc.rtld.nns. They implicitly increase the per-thread memory usage as necessary, so this tunable does not need to be changed to allow many audit modules e.g. via LD_AUDIT.

This LD_AUDIT idea apparently came from SunOS, decades ago. See https://sourceware.org/glibc/wiki/LinkerNamespaces:

In glibc the primary use case for dlmopen and multiple link namespaces was to implement the LD_AUDIT interface, also a Sun OS design, to allow users to write shared libraries which can inspect and modify the behaviour of the dynamic loader. The name "library auditing interface" is a bit of a misnomer since the API allows the loaded shared objects to manipulate much of the search path and symbol binding behaviours of the loader. In order to isolate these loaded libraries and hide them from the running application they were loaded into a new linker namespace. The new linker namespace gives them their own unique copy of libc.so.6 and that ensures that any references to things like errno are only coming from the namespace copy of libc.so.6.

Then I looked up musl libc: https://musl.libc.org/:

musl is an implementation of the C standard library built on top of the Linux system call API, including interfaces defined in the base language standard, POSIX, and widely agreed-upon extensions. musl is lightweight, fast, simple, free, and strives to be correct in the sense of standards-conformance and safety.

And that led me to https://ziglang.org/ and https://www.gnu.org/software/guile/manual/html_node/PEG-Tutorial.html, ... and now it's July 2014 and I'm back in Banais Cafe in La Paz, wondering WTF is the matter with everybody! See Commercial - N-able and this: real world semantics of the MOnSter 6502 using powerFET transistors (and a python program that traverses the netlist and calculates the necessary values of the pull-up resistors to make sure it can drive the gate-capacitance resulting from the fanout, ...) Semantics goes all the way down: Colleen Fazio on Carbon Composition Resistors and a Premier 71 Amp.

In total, there are 4769 components on the board. There are 3218 transistors and 1019 resistors that comprise the "functional" part of the 6502. In addition to these, there are also LEDs sprinkled throughout that indicate the values of various control lines, registers, and status bits, as well as additional transistors and resistors (not counted in those "functional" totals) that are necessary to drive those LEDs.

It draws up to roughly 2 A at 5 V, or 10 W total. The LEDs are a significant part of the power consumption.

The MOnSter 6502 runs at about 1/20th the speed of the original, thanks to the much larger capacitance of the design. The maximum reliable clock rate is around 50 kHz. The primary limit to the clock speed is the gate capacitance of the MOSFETs that we are using, which is much larger than the capacitance of the MOSFETs on an original 6502 die.

Subscribe to Zero To ASIC Course.