CPU Bugs: Difference between revisions

749 bytes added ,  29 days ago
m
Bot: Replace deprecated source tag with syntaxhighlight
[unchecked revision][unchecked revision]
(→‎SS selector: Added mitigation section to the SS selector bug)
m (Bot: Replace deprecated source tag with syntaxhighlight)
 
(3 intermediate revisions by 2 users not shown)
Line 47:
=== PUSH selector ===
 
On Intel CPUs, when running in 32-bit protected mode, the push will only modify the low 16bit of stack and write there the selector. The high 16 bits remains unmodified. AMD CPUs do not do this. It may have some security impact, that some of stack is not initialized.
 
The high 16 bits remains unmodified. AMD CPUs do not do this. It may have some security impact, that some of stack is not initialized.
Note: This applies to every time a selector is pushed to the stack. So both a PUSH instruction and an implicit push following an interrupt of some sort are affected.
 
==== Mitigation ====
When reading a selector value off the stack, always mask out the bits you are interested in. Very often, the important information is just the RPL of the selector (which already contains the information, whether the selector is kernel or user space), or the TI bit. The actual table index is rarely needed. Doing this also hardens all parts of the kernel that read selectors against modifications of the GDT later on.
 
=== Nesting of NMI interrupt ===
Line 76 ⟶ 80:
This bug is caused by executing LOCK CMPXCHG8B eax (F0 0F C7 C8) By containing two opcode errors, an unallowed lock and a non-memory target, together with trying to cache the results, it confuses the cpu to enter a deadlock state, locking up the entire computer involved.
 
To fix this bug, the [[IDT]] entry containing the invalid opcode should be marked as uncacheable or writethrough to eliminate one necessary factor, or by marking the same page as not-writable which further confuses the processor, this time into the pagefault handler instead of into a deadlock. If paging is to be left disabled, the only workaround is to disable the cpu's caches, which is far from efficient. Further discussion of various solutions is presented [http://web.archive.org/web/20070927195343/http://www.x86.org/errata/dec97/f00fbug.htm here].
 
We can check, if the processor is Pentium through the [[CPUID]] instruction. Calling it with EAX=1 will return the CPU signature in EAX. We can extract the Family Number from the CPU signature and compare it with 5, because the Pentium belongs to Family 5.
Line 92 ⟶ 96:
=== Core-microarchitecture Bugs ===
 
[http://web.archive.org/web/20190804131349if_/https://www.geek.com/images/geeknews/2006Jan/core_duo_errata__2006_01_21__full.gif See a list of known bugs as of 2006]
 
=== 'Meltdown' Page Table Bug ===
Line 125 ⟶ 129:
To fix this bug, one must write to the cyrix registers and set the NO-LOCK bit in CCR1, which disables all but the most essential bus locks. The downside of this is that read-modify-write atomicity is no longer guaranteed on multiprocessor systems. Source code that should prevent this condition: (untested)
 
<sourcesyntaxhighlight lang="asm">
MOV AL, 0xC1 ; 0xC1 refers to CCR1
OUT 0x22, AL ; Select Register
Line 135 ⟶ 139:
MOV AL, AH ; Load new contents
OUT 0x23, AL ; Write new CCR1 with No-Lock set
</syntaxhighlight>
</source>
[[Category:X86 CPU]]