6 ms·

For one plain text is a bit more convenient to view, edit, and talk about on line. And as you move up towards more complex capabilities, you can start adding s

by tux3 20d ago

For one plain text is a bit more convenient to view, edit, and talk about on line. And as you move up towards more complex capabilities, you can start adding simple features like comments and basic text macros to give a name to your common opcodes The bootstrap aims to use a progressively more capable language at the same time that the size of the next object to review increases. Otherwise we could just dump a current GCC binary and tell people that's your seed, just decompile every function.

moring 20d ago
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.
- tux3 20d ago
  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
  - moring 20d ago
    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.
    - tux3 19d ago
      >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.

by tux3 20d ago

moring 20d ago

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.

tux3 20d ago
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
- moring 20d ago
  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.
  - tux3 19d ago
    >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.