3 ms·
The fundamental problem was that x86 had no mechanism for verifying first instruction at the time (Boot Guard and Platform Secure Boot provide that now), and th
by mjg59 1y ago
The fundamental problem was that x86 had no mechanism for verifying first instruction at the time (Boot Guard and Platform Secure Boot provide that now), and the only way to try to deal with this was by adding immutable storage - but given where they put it, that was expensive, so small. And that led to making poor tradeoffs, influenced by having what was clearly not a great level of adversarial security analysis, but even implementing that perfectly they'd still have been fucked by the gate A20 thing which is maybe the absolute funniest legacy design failure that perpetuated well into the 21st century.
(The Intel/AMD difference on IP rollover is also funny but given the number of other ways to circumvent things...)
I actually use this as a teaching example - it's a great way to talk about how CPUs actually work and interact with other hardware, and a good understanding of this gives a lot of insight into low level platform design
- exikyut 1y agoI have a vague idea the A20 gate was also used to defeat Intel SGX a couple years back, if I'm remembering correctly?
- ethan_smith 1y agoThe Xbox 360's security was also compromised despite Microsoft's improvements, with the hypervisor eventually being defeated through clever timing attacks and hardware modifications like the JTAG/RGH exploits.
- rep_lodsb 1y ago>Intel/AMD difference on IP rollover Never read about this before, but the explanation in the wiki seems made up to me. The way it's described makes it sound like yet another legacy "feature" that's been there forever, but older x86 CPUs did not (generally) behave like this. The 8086 (and 186) did wrap around of course, because they had no memory protection and only 20 address lines. But I know for a fact that the 286 would fault and invoke interrupt 0Dh [1][2]. I'm fairly certain the 386 did so as well. Segment limits are enforced even in real mode, and at reset they are initialized to 64K. Or is the CPU already in protected mode, and segment limit set to 4G? In that case Intel and AMD might differ. (The 286 was 16-bit, so 64K was the maximum there. Arguably, the "correct" behavior for 386+ would be to do the same thing when the limit is 4G) What it says about opcode FFFFh however is even more likely to be wrong. That opcode has always been undefined, only the original 8086/8088 ("1970s stuff") would execute it, but as PUSH DI instead of NOP. It's not impossible that Intel made the decision to interpret it as NOP in some later generation, without ever documenting it. But I just tried this on my modern-ish Intel machine, and it aborted with "Illegal instruction". [1] third post in https://forum.vcfed.org/index.php?threads/286-cpu-experiments.1253659/ https://forum.vcfed.org/index.php?threads/286-cpu-experiment... [2] also note it isn't a double fault (interrupt 8). And shutdown occurs on a "triple fault", i.e. when the CPU fails to invoke the double fault handler.
- rep_lodsb 1y ago(can't edit anymore) I should have read the entire article first - of course we are in protected mode, and with no exception handlers defined in the IDT it would triple fault. I stand by my comment about FFFFh, this isn't a NOP on older or newer CPUs, so almost certainly not on the Pentium III either. As to what happens on 4G wraparound, I could only find this in the Intel manual (SDM Vol. III, 5.3 Limit checking): >When the effective limit is FFFFFFFFH (4 GBytes), these accesses [beyond the segment limit] may or may not cause the indicated exceptions. Behavior is implementation-specific and may vary from one execution to another.