IRC channel logs

2021-12-30.log

back to list of logs

<oriansj>muurkha: it happens. Besides hardware bootstrapping is going to be a wonderful challenge and solving the Nexus Intruder problem is going to be much more work to solve.
<stikonas>the problem with hardware bootstrapping is that it is not as scalable as software bootstrap. Anybody can easily run stage0-posix or live-bootstrap and it only takes a few hours. Yet doing hw bootstrap yourself is hard.
<stikonas>and to be sure that it is properly bootstrapped, everybody has to do it him/herself
<oriansj>stikonas: very true. But that is the great secret of hard problems, you first have to solve the smaller slightly easier problems inside them first.
<bauen1>oriansj: what is the nexus intruder problem / are there more ressources on it ?
<bauen1>stikonas: it depends on how you organize it, e.g. you could reuse many approaches and even large amount of code between many different ARM processors / SoCs
<bauen1>stikonas: e.g. what i'm trying to do, writing to SPI flash with switches, can be reused for other boards, and basically every bit of code except some drivers and platform specific code can be reused
<bauen1>stikonas: and you don't need that many drivers either, you need at least an UART and SPI driver, and if you're trying to write a posix-like kernel, probably support for interrupts, mmu, task switching, dram (and if you're feeling particularely fancy a network card)
<bauen1>stikonas: thankfully at least some are pretty much standarized between ARM systems
<bauen1>stikonas: unless you're talking about building the actual hardware, which will be limited by how much money and time you can spend than anything else probably
<stikonas>well, yes, baremetal bootstrap is somewhere in the middle
<stikonas>but actually hardawre is much more involved
<lagash>Are there any books on bootstrapping? Like, dead tree manuals in case the apocalypse happens, etc?
<oriansj>lagash: bootstrapping civilization: yes; bootstrapping software/computer hardware: no
<oriansj>bauen1: The Nexus Intruder program was a (still very classified) paper written by the DoD in 1958 speculating that computer hardware will be designed in software. Then it basically proposed essentially a hardware trusting trust attack that compromises software; which in turn ensures future hardware is compromised too. creating an unbreaking chain of compromised operating systems and hardware that the United States could forever use
<oriansj>against the Soviet Union.
<oriansj>In short if software is used in the design and/or manufacture of hardware, you can't be certain that it isn't going to subtly change the output to produce something which gives a backdoor to an attacker.
<oriansj>unless one has a chain of trust from human creation of computers all the way to current computer controlled manufacture of chips.
<muurkha>interesting, I hadn't heard about that
<oriansj>it as of this moment is entirely theoretical only as we have no idea if the DoD did ever convert the idea into reality and use it against the Soviet Union. As it would first require implementing a trusting trust attack and getting it to stick in an era where most things were done in assembly and compromising the units that build silicon chips in the Soviet Union.
<oriansj>These days however, I think such an attack would be quite cheap to do for a government
<muurkha>it sounds a lot more difficult than the software version
<muurkha>because the compromised software has to somehow figure out how to insert the self-propagating backdoor into CPUs that hadn't been invented yet when the initial software was written
<muurkha>that's a lot more difficult than a compiler recognizing itself
<muurkha>you could do it with a human in the loop: exfiltrate the unfinished CPU design to the tiger team, who figures out how to backdoor it and then infiltrates the backdoor back to the trojan
<oriansj>I have no doubts that it is a much bigger task than a drinking night project for Thompson but one can't help but wonder if their funding of Computer design for hardware didn't enable them to ensure certain hooks would exist
<stikonas[m]>Even Thompson needs basically AI engine to propagate
<stikonas[m]>So I doubt propagating HW version is feasible even with large funding
<stikonas[m]>Hiding non-propagating backdoors is probably more realistic
<oriansj>stikonas: well shutdown backdoors are trivial
<oriansj>a single transistor attached to turn off power
<stikonas[m]>Well yes, backdoors in hw should be as simple as in software
<stikonas[m]>As long as it doesn't propagate
<oriansj>stikonas: that is where I disagree but I can imagine your perspective.
<oriansj>it is a hard problem to implement and defense against it requires a large group to trust or some really clever engineering.