Stack Usage Graphs

Software and firmware at Prolaag are developed under the same JPL guidelines used for mission-critical spacecraft modules. This standard imposes some rather harsh restrictions on coding practices for the sake of rock-solid stability and correctness, and one of the most important of these is the complete prohibition of direct and indirect recursion.

Avoiding all forms of recursion allows us to fully characterize our stack under all possible function call paths. Here’s a graphical representation of the stack for the high-water mark of each possible call path in our red-side library:

Each column represents a single function call traversal to its deepest point, and each segment represents the stack frame associated with each constituent function call. Here, one vertical pixel represents 4 bytes of memory, and since the deepest stack traversal bar is 404 pixels tall, that gives us a maximum stack usage of 1,616 bytes. That’s it. 1.6kB of stack space to provide AES and OTP encryption; to serve DHCP, DNS, SIP, TFTP, and HTTP over a custom TCP/IP stack; to provide software and hardware encryption and entropy auditing; to negotiate RTC connections for video conferencing; etc. Combine this 1.6kB figure with the fact that JPL coding standards forbid dynamic memory allocation after system startup, and you start to get a sense of the ruthless asceticism with which we pursue security through code clarity and minimalism.

Conditions on the Internet-facing black-side are even more austere. Here’s the coresponding graph of its stack usage:

With a maximum stack depth of 832 bytes, this library contains only enough code to route IP packets - it doesn’t even “speak” TCP. Put another way, the text of this blog post is about the same size as the combined stack usage of both halves of our appliance. The goal is to provide would-be attackers a barren, featureless attack surface where cracks and bugs simply have no space to hide, much less flourish. In this, we at Prolaag succeed wildly.

As such, “getting root” on our device is non-sequitur; there is no root account, nor any concept of users. There is no operating system, no shell, no third-party dependencies, no IPC, no concurrency. No files on the device can be corrupted because it has none; the Internet-facing side lacks even the hardware capacity for persistent storage. This is why we named the company after Dijkstra’s (https://en.wikipedia.org/wiki/Edsger_W._Dijkstra) semaphore term, “prolaag” - it’s shorthand for “probeer te verlagen”, try to reduce.

Share this Post: