@thecsb@mastodon.cloud the real issue is that the ai can also implant state sponsored backdoors
Timeline
Post
Remote status
Context
25
@DavidB@noauthority.social @thecsb@mastodon.cloud LLMs aren't open source unless they give you all the data needed to regenerate the model weights
@DavidB@noauthority.social @thecsb@mastodon.cloud that's like saying you don't need any source code when you can get a compiled binary but it's still open source somehow
@DavidB@noauthority.social @thecsb@mastodon.cloud a binary executable/library is a "compressed" rendition of its source code in the same way weights are a "compressed" rendition of its training data.
@DavidB@noauthority.social @thecsb@mastodon.cloud the training process "translates" the training data into optimized weights using gradient decent and back propagation in the same way a compiler "translates" source code using parsing lexing building an AST, transforming the AST to IR, IR is optimized, IR is transformed into machine code.
both are "translating" and "compressing" fat enriched source data into a thin opaque binary output in a one way manner.
@DavidB@noauthority.social @thecsb@mastodon.cloud if you genuinely think compilation is deterministic you clearly never used -O3
@DavidB@noauthority.social @thecsb@mastodon.cloud gcc uses the inode of intermediate object files in the final compiled executable among other non deterministic data sources (e.g. timestamps) , you're just wrong.
@DavidB@noauthority.social @thecsb@mastodon.cloud additionally the final binary layout under -O3 is non deterministic
@jeff @thecsb if you give the compiler the same inputs, including flags, you will get the same out.
In the situation you're describing the inputs are being changed on each run. You can think of a compiler as a function. And your source code is not the only input.
Some compilers make controlling inputs impossible, thus you can't get a bit-for-bit binary that's identical for each compiler run.
Compilers are deterministic. For a given set of inputs you will get the same output.
@DavidB@noauthority.social @thecsb@mastodon.cloud "if you give the compiler the same inputs, including flags, you will get the same out. "
no, no it won't. compile a program with multiple compilation units using -O3, sha256sum it, remove all the compiled binary and object files and repeat. you'll find the hashes do not match.
We need a single threaded KVM implementation that is reproducible. And probably also should be able to create a log of inputs, so you can launch a VM and fiddle around in it, then when you hit a bug, you can re-launch and replay the same inputs and arrive at the same state.
@cjd@pkteerium.xyz @thecsb@mastodon.cloud @DavidB@noauthority.social debian has gone thru literal hell on earth to get deterministic builds working, to say that compilation is always deterministic is just so fucking ignorant of the actual reality of software infra.
that's why this thread exists
If the VM is deterministic then it's impossible for the build to NOT be deterministic.
Obviously you can't have internet access, and the clock is going to be doing Groundhog Day...
Obviously you can't have internet access, and the clock is going to be doing Groundhog Day...
@cjd@pkteerium.xyz @thecsb@mastodon.cloud @DavidB@noauthority.social i know and i want a deterministic pony
IMO deterministic VM is an easier problem than deterministic build - because you only have one place that you need to solve and that is in the clock.
@cjd@pkteerium.xyz @DavidB@noauthority.social @thecsb@mastodon.cloud what about interrupts?
There's only two devices that you NEED and that are going to generate interrupts.
1. Disk drive -> Do the easy thing, pause the VM until the disk replies so to the VM it's synchronous.
2. Clock -> Like I said, this is the fiddly part.
The other device you probably want is an output-only serial console, but since it's one-way it should never generate an interrupt.
1. Disk drive -> Do the easy thing, pause the VM until the disk replies so to the VM it's synchronous.
2. Clock -> Like I said, this is the fiddly part.
The other device you probably want is an output-only serial console, but since it's one-way it should never generate an interrupt.
@cjd@pkteerium.xyz @thecsb@mastodon.cloud @DavidB@noauthority.social doesnt the mmu use a hardware interrupt for page faults? there's not just disk and clock, i can see something cursed with fpu too, x86 be like that sometimes.
Oh yeah I forgot about page faults, that's an "exception" but not a normal numbered interrupt. Should be okay though b/c single threaded and you don't have to wonder when it's going to come, it comes immediately when you touch the page. Same with the FPU, it kicks back an exception immediately when you divide by zero or whatever.
The key is to make sure the clock lies so that you're not able to time any of these things...
The key is to make sure the clock lies so that you're not able to time any of these things...
@cjd@pkteerium.xyz @thecsb@mastodon.cloud @DavidB@noauthority.social honestly the speculative execution from the host machine is the biggest danger for determinism in this setup regardless of how hard you work at it
Replies
5The way you attack speculation is by timing different memory accesses. The actual job is to make it so that the VM clock is entirely divorced from true time.
@cjd@pkteerium.xyz @thecsb@mastodon.cloud @DavidB@noauthority.social the clock needs to advance deterministically being divorced from "real time", yes. i feel like there's so much specex going on that vm execution itself could suffer non determinism if not carefully managed, e.g. out of order guest memory writes because of specex on host
The CPU is supposed to guarantee that a single thread will see the world exactly as it left it at any given time - and AFAIK they're all pretty much perfect at this. Where you get a can of worms is when multiple threads are touching each others' memory.
The way the fake clock needs to work is basically when you power on it's T0 and you add a nanosecond for every instruction executed. Then when it schedules and idles the processor, when it re-awakens, the clock is set to whatever time it was scheduled to re-awaken and it goes on again adding a nanosecond per instruction.
The way the fake clock needs to work is basically when you power on it's T0 and you add a nanosecond for every instruction executed. Then when it schedules and idles the processor, when it re-awakens, the clock is set to whatever time it was scheduled to re-awaken and it goes on again adding a nanosecond per instruction.
@cjd@pkteerium.xyz @DavidB@noauthority.social @thecsb@mastodon.cloud i wonder how much of the linux kernel cpu scheduler depends on hardware specific dark magic that breaks if it's not true. doubt linux would run right in this vm tbh.
What I just described would definitely work, because it's realistic that a real clock could do precisely that.
Just imagine a single core processor where every instruction takes the same number of cycles and every time you set a clock event, it triggers precisely when you asked it to.
Just imagine a single core processor where every instruction takes the same number of cycles and every time you set a clock event, it triggers precisely when you asked it to.