Hello Aleksandar,
On Mon, Jul 13, 2026 at 08:44:22PM +0200, Aleksandar Kuktin wrote:
> >On Mon, 13 Jul 2026 18:43:58 +0200
> >[email protected] wrote:
> > So we are back to learning/teaching as the only rational (in contrast
> > to emotional) reason to do development of bootstrapping.
>
> Certainly, it is not logically necessary to bootstrap the new system.
> Yet, ordinarily, a newly invented system will at some point bootstrap
> itself to prove it's sufficiently capable to carry the full load of
> information processing.
This is something I must have missed? Did e.g. Linux on riscv bootstrap
itself from machine code, without using cross-built bootmedia and
compilers? I assume "no".
If someone had done this, it only would prove a capability to do certain
kind of software bootstrapping, nothing else.
Apparently this is your definition of "to carry the full load of
information processing".
This is a circular argument - the usefulness of doing X is that we know
that X is possible. Why would we _need_ X remains unanswered.
> at one point you yourself reject the
> notion VSOBFS can serve it's purpose without bootstrapping. It's in the
> Limits to Verifiability document, under the heading "What about
> reducing the a priory trusted set?"
It looks like you do not distinguish between creation of binaries of a
software environment and booting a computer. The referred text tells how
VSOBFS potentially can improve one's trust in a _hardware_ platform by
verifying its firmware. This is not a dependency of VSOBFS in any way,
but its possible additional usefulness.
> All of the quibbling is merely if
> you have to start with hand-assembled code or if you can do consensus
> heuristics. And I for one reject the idea we can use heuristics for
> things as important as these, thought I don't deny their utility.
Unfortunately I can not comment, unless I know what you mean by
"heuristics" and why.
The document you refer to does not use this term.
> Take for instance the systems on which I might run VSOBFS: two laptops
> from mid-2000's, one of which is almost guaranteed to house an implant,
> another laptop and two desktops from late 2010's and an old Olivetti
> M24. The ONLY system here I'd even remotely trust is the Olivetti, and
> it's in the minority. Thus, following your prescriptions, if the
> Olivetti is the sole one that produces a different binary, I'd be
> required to discard it's output and take the "consensus" one?
You have also access to others' results. Did your computer actually produce
a different checksum for the disk image than shown on the VSOBFS sites?
> > It can only if you assume it to be feasible to silently and
> > successfully corrupt a majority of platforms suitable for checking
> > VSOBFS (among others all the current major platforms), with a payload
> > specifically directed to subvert and fake the outcome of VSOBFS.
>
> I assume that. Now what?
Then you have moved the goalposts.
It is no longer the "trusting trust" but a global corruption of majority
of computer systems.
> And it's not an idle assumption, either. Remember how STUXNET was
> discovered? On a CD sent to Russian researches after a professional
> conference they were on. Have we forgotten NSA's TAO? You're not
> paranoid if you think "they" are able to infect vast swathes of
> computers. Here's another one: back in 2012, a dude infected most of
> home routers to "conduct a census of Internet", the Carna botnet. The
> thing most people overlook was that the Carna botnet guy *discovered
> another botnet* on about half of routers he infected!
I hear what you say.
My point is that if VSOBFS is attacked globally (which is harder than
attacking routers, VSOBFS is not a network-connected device, you have to
corrupt many and varying systems) then the problem it is meant to solve
is no longer important. Note that it is not "trusting trust" which was
deployed against the routers.
At any rate, "bootstrapping" which is the Subject would not hold against
such an attack either. A corrupted boot preparation system has free hands
to subverts bootstrap.
> Not to mention the Go compiler injects telemetry into it's output by
> default. The corruption is not silent, not really. And let me not tell
> you of a story I heard, of a US laborer working for a German router
> manufacturer, who for years added an additional chip to the routers he
> was assembling. And then disappeared into USA when his machinations
> were discovered. But that is a story I heard from a fellow participant
> in a security seminar a bunch of years back. Carna, TAO and TPM
> were/are real.
This is not a problem we are talking about, nor does "bootstrap"
provide protection from it.
> I myself have at one point witnessed the existence of a TCP-terminating
> function in a router used by a web-coding shop. That's not something
> such routers ordinarily posses. Was it infected? I also posses a laptop
> (currently in parts but could be reassembled) that has a two-core CPU,
> yet which reports only a single core internally to the OS. To make
> matters more interesting, it's chipset has never been documented as
> being able to support multi-core CPUs, and putting that CPU into
> another laptop of the same make and model fails to boot - they didn't
> lie about the chipset.
See my comment above.
> And then TPM 2.0 and Microsoft pushing that onto everyone. Did you know
> Apple is working to ensure it's servers, shipped all over the world,
> are unassailable by people who have physical access to them? On it's
> own that's not weird, but then you remember Apple devices are
> specifically designed to be tamper-proof, encrypted, and unable to
> export the information on them. Put those two facts together, and
> suddenly you're not sure if Apple is trying to enslave it's users.
As above.
> So in summary, yes, I absolutely believe it's feasible to corrupt the
> majority of computers worldwide. It's why one of my desktops was
> *never* connected to Internet, and never will be.
An air gap can be jumped over by malware. Be careful.
> > With most of the platforms corrupted in a coordinated way we have
> > though not the original "trusting trust" problem but a much larger
> > one.
>
> One you have to solve if you want SSSBEA-CORDB and thus VSOBFS to take
> off. You should at the very least stop insisting VSOBFS is a silver
> bullet,
I never said that. VSOBFS solves the problem it is meant to solve
(the "trusting trust" one, well known since 1984) and shows a way
to approach other problems. So much for a "silver bullet".
> and most of all, you should stop insinuating other people's
> efforts are wasteful and unnecessary (here I mean the comments
> regarding Michael's work).
Indeed, the large effort spent on modern old style bootstrapping,
i.e. from the machine code, could be seen as wasteful, but I have high
respect for the learning and emotional value of such a work.
I just insist, yes I do, on being conscious and open about what its
purpose is.
> Various schemes to create a secure machine from scratch are in
> general immune to this problem. Yes, there are computers build with
> 7400 logic chips, and there are even computers build with discreet
> transistors.
This is addressed in README of VSOBFS: "Even a hypothetically present
suitable platform, say built from vacuum tubes made by oneself, would
be insufficient. Hardly anyone else could duplicate the building effort,
to be able to verify the result."
> > Still, remaining hard copies of bootmedia of VSOBFS from before the
> > attack could serve as a safety anchor.
>
> The attack happened 15 years ago at the latest. It predates VSOBFS by a
> decade.
Do you mean that the a global corruption of various systems, specifically
crafted against VSOBFS happened a decade before its invention?
I do not know which attack you were thinking about, but this had nothing
to do with the cited text of mine.
> > > On the other hand, the hex0 to tcc-0.9.26/janneke bootstrap is a
> > > fully verifiable source path.
> >
> > This is, sadly, not true.
> >
> > 1. hex0 is not a source, but the codes, exactly as they are to be
> > interpreted by the CPU. It is expected to be interpreted by the CPU,
> > right?
>
> At some point you need to be the binary interpreter.
Not with VSOBFS.
> At the very least, you need to either assemble or disassemble the binary
> image.
> It's the only way. There is no other option. Bonus points for stamping the
> paper
> tape yourself.
It _was_ once the only way.
Nowadays you can use programs to translate from the languages specifically made
to be palatable for humans. It is also what VSOBFS does.
> You could always output it onto a punch tape, print out the tape,
This is not true.
There are now very few people in the world who easily can do this.
> verify the printout, then load the tape back into the computer. In
> addition, some people are able to read binary straight from the tape.
> It's not that difficult, thought I never actually looked at a tape,
> only ones and zeros on the screen. Also, you could always punch the
> tape as you're performing the assembly.
What you describe is how it was many decades ago, but it is no longer.
> > Some running binary blob must be involved to visualize the
> > contents of some file.
>
> Which is why, if you truly want information security, you need to
You are moving the goalposts again.
"All world's problems" are out of scope.
> start with the hardware. Strictly speaking, any and all x86 systems
> build after about 1988 or so, and all ARM systems, are to be assumed
> compromised. I don't know about RISC-V, but from what I know, it too
> is too big to be effectively audited, to include the audit of the IC
> under a microscope. Yes, we're looking under a microscope. Do you want
> security, or do you just want security theater and recognition for
> solving arbitrary logic problems with real-world implications?
I strongly dislike security theater and that's why I insist on clarity:
VSOBFS
- shows that under quite reasonable assumptions the problem of the
"trusting trust" compiler backdoor has an actual practical solution,
- provides an implementation of the solution.
No more no less.
For the same clarity's sake:
"Bootstrapping" from machine code on modern hardware does _not_
provide a solution of the "trusting trust" compiler backdoor problem
(regardless of whether the hardware behaves or not). It can not provide
any proof that the actually run boot code corresponded to its explorable
presentation. Irrespectively of the size of the intended starting code
the boot unavoidably depends on preexisting external binaries.
The only known proof of a bootstrap's validity remains multiple
diverse reproducible recreation. At the same time, such proof can be
obtained much more efficiently without starting from manually crafted
machine code.
Bootstrapping from machine code to a full OS deserves due respect as
a technical feat and as a learning/teaching ground.
But: not as a security measure.
To conclude, I would like to once more thank you Aleksandar and others
for the interest in compiler bootstrapping, in security and in the role
of VSOBFS in this context.
Happy hacking / usage of tinycc to everyone.
Kind regards
/tccm
_______________________________________________
Tinycc-devel mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
