The designers of the firmware anticipate this attack but punt it to the vendor, apparently:
//
// Platform implementor should choose a timeout value appropriately:
[snip]
// - The timeout value must be longer than longest possible IO operation in the system
I don't know much about the specifics of CPU architecture apart from the existence of assembly and different modes. Either way the explanation was still entertaining and interesting. smiiiiiiii
I'm amused at the lengths the readme goes to in order to drive home the fact that this needs to be a LOOOOOOOOOOOOOOOOOOOONG instruction, including the unnecessarily long code block illustration. The topic is interesting anyway, but that makes it way more entertaining.
Is it really a long running instruction? I mean, obviously yes, but what makes it slow is that it's doing an MMIO copy from a slow source. It's like a read(2) system call being "slow" because the fd is associated with a socket to the moon.
It's an instruction in the sense that timing boundaries are x86 instruction boundaries, which is what the security model bases itself on. So yeah, not an instruction in the strict CPU sense (microcode + micro-ops), but in the useful sense.
The designers of the firmware anticipate this attack but punt it to the vendor, apparently:
I don't know much about the specifics of CPU architecture apart from the existence of assembly and different modes. Either way the explanation was still entertaining and interesting. smiiiiiiii
I'm amused at the lengths the readme goes to in order to drive home the fact that this needs to be a LOOOOOOOOOOOOOOOOOOOONG instruction, including the unnecessarily long code block illustration. The topic is interesting anyway, but that makes it way more entertaining.
Do you think a short instruction is okay or does it need to be long? The instructions were a bit unclear in that regard :D
Only if the short instruction is incredibly long.
Unclear why there is a 1 second timeout at all.
Presumably the patch for that will be to make it an infinity timeout.
Can this be patched? Is there a chance it's a hw watchdog that you can't fix in microcode?
Looks like it's ~4 billion (2^32) crossover counter?
...huh, I was wondering why serial machine code prankster xoreaxeaxeax was keeping lists of extremely long-running instructions.
Hopefully this is at least only possible in kernel mode, right?
Right?!
Is it really a long running instruction? I mean, obviously yes, but what makes it slow is that it's doing an MMIO copy from a slow source. It's like a read(2) system call being "slow" because the fd is associated with a socket to the moon.
It's an instruction in the sense that timing boundaries are x86 instruction boundaries, which is what the security model bases itself on. So yeah, not an instruction in the strict CPU sense (microcode + micro-ops), but in the useful sense.
Maybe with vfio/igb_uio/uio_pci_generic? Still root level access.