Originally posted by Weasel
View Post
Originally posted by Weasel
View Post
If you had gone into effected cpus by the vulnerability you would have worked out that its a CPU defect. With Microsoft agreeing to drop win16 support ( so dropping need for 16 bit protected mode) at the same time they dropped dos support(vm86 mode) as well there was little pressure on Intel or Amd to fix the fault at CPU level.
Yet you see attempts at microcode fix from Intel and AMD for espfix32 all the way back in 2002 that also shows the problem is not instruction set its cpu defect..
By the way the 16 bit protected mode fix is more complex than the 32 bit version because it in fact patching more defects the 32 espfix is less complex because some of the defects around it are fixed by microcode in older cpus.
Current LInux kernel runs on the presume on x86-64 that when switching to and from protected mode 16/32 that the cpu is broken and runs the software work around every single time so security flaw is sealed by software. /proc/sys/abi/ldt16 was a temporary stop gap while the information to exploit the protected mode 16 defect and a patch covering all the issues did not exist. Basically /proc/sys/abi/ldt16 allowed you to down grade your kernel security so you could still run like win16 applications in wine. .
Really old x86-64 amd/intel cpus running without updated microcode will see that the 32 expfix is not complete. So sections of ESPFIX issue can still come back and bite you if you are using really old hardware due to being part microcode update and part software fix.
Was the vulnerability in the cpu with protected mode 16 handling(espfix16) in long long mode in fact fixed the answer is no. Anyone writing a OS wishing to be 64 bit on x86 cpu in long long mode using 16 bit protected segments need to include full software fix for this. Was the vulnerability in cpu for protected mode 32(espfix32) in long long mode in fact part fixed half fixed by microcode/cpu silicon update. So anyone writing a OS wishing to be 64 bit on x86 running 32 bit protect mode need to check that update microcode is applied and software fix what the microcode does not. Yes protected mode 16 could have been half fixed by microcode as well.
CPU faults operating systems learn to live with. But the number of faults in x86 is starting to get insane. Each software fix to a hardware fault is wasting cpu time that could be used on other things.
Comment