Comment by moring | Hacker News Reader

Comment by moring | Hacker News Reader

Parent Full thread

Opcode mnemonics is something that a tool can show when you inspect a binary. You will need to go up the ladder a lot before the source code is more expressive than a disassembly. Comments are a good point though, but since they do no affect the semantics, they could be provided as a separate file that does not have to be reproducible (since compromised comments are at worst misleading or confusing).

The GCC example is valid, but can also be explained by its size.

I like the idea of bootstrapping in a Lisp-like language since it is extremely expressive for its simplicity. But then you need an interpreter for that, which must be trusted. I've been nerd-sniped by the whole thing and I'm thinking about an extremely simple virtual machine for the seed, with the actual seed code being a binary for that VM that implements a Lisp. Then an audit of the seed becomes disassembling the VM code for the Lisp interpreter, which is only moderately complex because the VM is as simple as possible.

People are doing that with lisps and schemes, but then the interpreter keeps growing. People start to want more expressivity, it needs optimizations so that you don't go mad trying to write a compiler with it and needing to wait 15min between test runs.

That compound if your lisp interpreter is itself running as a bytecode for an extremely simple VM interpreter.

I don't think it's a bad idea, but you will quickly end up with a growing pile of esoteric code and binary that only you really understand

The more I think about it, the more I think that bootstrapping the build isn't actually the huge problem it first seemed to be. There are practical problems to solve, but they CAN be solved.

In contrast, how can you make sure that the actual payload code hasn't been tampered with? It is written in a high-level language, but it gets stored and viewed on devices that have backdoors in their CPU microcode and huge OSes that can hide god knows what. The author can sign the code, but that doesn't tell anything other than it was really the author who signed it and the code hasn't been modified afterwards -- if the author's system was compromised, the code can contain backdoors before being signed. So you need to validate the (signed or not) code to be correct, but you're doing so on an untrusted system. It goes on and on.

You'd probably need the code to be verified, then signed, by a trusted party on a trusted system. THAT signature then means the payload hasn't been tampered with, and can be trusted after it gets built on your trusted system (and this is where the bootstrap problem happens, and gets solved).

All this is obviously still glossing over the problem how to obtain hardware you can trust.

...edit: But if you have all that, then you don't need a complex bootstrapping anymore. A trusted actor can verify, or even build, a trusted system by hand on trusted hardware, sign it, and then you can use that (binary!) as long as you run it on your own trusted hardware and verify the signature first.

The bootstrapping then becomes a tool to ensure reproducibility, but is no longer needed for trust.

>as long as you run it on your own trusted hardware and verify the signature first.

I think that depends how far you want to take the paranoia. In principle if you want that to be a secure signature that can't be forged, you're back to needing both hardware and software you trust to verify the signature. Hashing a large binary and verifying a signature on paper is wildly impractical.

If someone prints the code and claims they verified it, you could trust them. But if they give you a signed archive that you download and verify on your computer, you're back to square one. You would have to know your software and hardware isn't already backdoored, just to verify that the software you received isn't backdoored.

>A trusted actor can verify, or even build, a trusted system by hand on trusted hardware, sign it, and then you can use that (binary!) as long as you run it on your own trusted hardware and verify the signature first.

Your own trusted hardware AND software, because you're not going to be verifying that signature by hand, and you're not going to load the binary file in memory by hand, so either a kernel or system software (like UEFI) will be handling your trusted binary first.

But then you're back to needing a clean bootstrap again. Which is why the chain starts with a hex0 that you can type manually, not with a large signed binary that would require either an already trusted system, or cryptography that's realistically not possible to do by hand.

> because you're not going to be verifying that signature by hand

At least verifying a signature is something that does not need complex hardware, so chances are that your trusted hardware can do that.

> Your own trusted hardware AND software, because you're not going to be verifying that signature by hand, and you're not going to load the binary file in memory by hand, so either a kernel or system software (like UEFI) will be handling your trusted binary first. > > But then you're back to needing a clean bootstrap again. (...)

But having solved that bootstrapping problem, you are likewise back to square one with trusting "the payload", only this time the payload isn't the actual payload but the OS kernel, UEFI or whatever that obtains and verifies the actual payload.

You have that OS kernel or UEFI as source code, but you don't know if the source code contains a backdoor unless you either verify it manually, or have it verified and signed in some way by a third party you trust, and there the whole signature thing comes back.

(BTW thanks for the discussion. I'm really enjoying this!)

I was thinking an FPGA with an open toolchain might make a pretty solid hardware seed that can fairly easily be replicated, without needing your own fab or anything completely impractical. In theory the FPGA could still try to recognize and backdoor a bitstream right when you load it, but practically there's a whole bunch of different open-source cores that you could load on the FPGA, and it would be very hard to try to recognize and backdoor all those potential designs at the netlist level, or at least it would take a suspiciously large area, potentially visible as clearly more complicated than what should be needed on a microscope.

You could maybe distribute these verified boards that are just the FPGA and the verified CPU core + kernel + software seeds all stored on a basic NAND flash. But then instead of writing a lisp interpreter in machine code as your seed.. the seed would have to be an entire basic CPU that runs something like hex0, or like a basic lisp machine. You'd plug a keyboard into it and bootstrap the rest from there. But good luck with that, I'm not volunteering to try to make all of that work!

Plus there's still a small chance of a hardware backdoor somehow powerful enough to recognize any possible core you can load on it, or that the tools you use to even load a NAND flash or the NAND flash itself could be backdoored, so really we're just displacing the problem a bit further every time. But if you want to bootstrap everything from nothing, then you basically have to jumpstart all of computing electronics back up from nothing.

(And yeah, this is fun to think about!)

Isn't a sectorlisp running on a microcontroller a more straightforward solution? Detecting and modifying a sectorlisp on the fly would require something like a frontier LLM with latency on the order of fractions of a second.

Reply on news.ycombinator.com