laurenth
Joined 2 years ago
Karma
463
Submissions
21
Member since
Mar 2
https://github.com/laurenthuberdeau
View on Hacker NewsRecent submissions
Comment · 7 months ago
A shell is almost always used to setup the bootstrap environment, so the dependency on a shell is more or less always there.
Otherwise, something special with POSIX shell is its large number of independent implementations, making it the ideal starting point for diverse double-compilation (https://arxiv.org/abs/1004.5534). The idea is to bootstrap a toolchain from multiple compilers (shells in this case), and the result compared to verify that no shell introduced a trusting trust attack.
Comment · 1 year ago
Author here,
> assuming the resulting shell script is as inscrutably as binary executable
It's quite the opposite, pnut generates shell code that's close to the original C code to make it easy to audit the code. A useful way to see pnut is as a tool that rewrites C code to POSIX shell, without significantly changing the structure.
This means that even if GCC is required for the initial compilation of pnut (GCC compiles pnut, then pnut compiles itself and we get the pnut-sh.sh script), the script can be "sanitized" from trusting trust attacks by simply comparing the script to the C code and making sure GCC hasn't introduced any malicious code.
Page 10 of the SLE24 presentation has a tombstone diagram showing the compilation steps to go from pnut's C code to a GCC binary: https://github.com/udem-dlteam/pnut/blob/main/doc/presentati...
Comment · 2 years ago
We haven't found this to be an issue for Pnut. One of the metric we use for performance is how much time it takes to bootstrap Pnut, and dash takes around a minute which is about the time taken by bash. This is with Pnut allocating around 150KB of memory when compiling itself, showing that Dash can still be useful even when hundreds of KBs are allocated.
One thing we did notice is that subshells can be a bottleneck when the environment is large, and so we avoided subshells as much as possible in the runtime library. Did you observe the same in your testing?
Comment · 2 years ago
That's the idea!
As you point out, it moves the trust from the binary to the shell executable, but the shell is already a key piece of any build process and requires a minimum level of trust. The technique of bootstrapping on multiple shells and comparing the outputs is known as Double Diverse Compiling[0] and we think POSIX shell is particularly suited for this use case since it has so many implementations from different and likely independent sources.
The age and stability of the POSIX shell standard also play in our favor. Old shell binaries should be able bootstrap Pnut, and those binaries may be less likely to be compromised as the trusting trust attack was less known at that time, akin to low-background steel[1] that was made before nuclear bombs contaminated the atmosphere and steel produced after that time.
0: https://dwheeler.com/trusting-trust/ 1: https://en.wikipedia.org/wiki/Low-background_steel