Linked by Thom Holwerda on Mon 29th Jan 2018 23:17 UTC
Windows

Microsoft has released an update that disables Intel's microcode Spectre mitigations.

Intel has reported issues with recently released microcode meant to address Spectre variant 2 (CVE 2017-5715 Branch Target Injection) - specifically Intel noted that this microcode can cause "higher than expected reboots and other unpredictable system behavior" and then noted that situations like this may result in "data loss or corruption". Our own experience is that system instability can in some circumstances cause data loss or corruption. On January 22, Intel recommended that customers stop deploying the current microcode version on affected processors while they perform additional testing on the updated solution. We understand that Intel is continuing to investigate the potential effect of the current microcode version, and we encourage customers to review their guidance on an ongoing basis to inform their decisions.

This whole thing is a mess.

Permalink for comment 653374
To read all comments associated with this story, please click here.
RE[3]: No solution
by Megol on Wed 31st Jan 2018 15:45 UTC in reply to "RE[2]: No solution"
Megol
Member since:
2011-04-11

The separation of user space and kernel space has been a specified feature (Privilege levels) since the Intel 386 (possibly earlier) on the x86 architecture. Meltdown blurs the line between the two as speculative execution seems to be able to speculate with kernel space data from user mode processes and allows the speculated kernel space data to be leaked to user space. If the leaking did not occur the feature would be working as designed.

In my opinion this is a bug that requires software mitigation for current Intel CPUs and hopefully the next generation of Intel CPUs will not be susceptible to Meltdown.


My option is also that Meltdown is a bug - but Spectre obviously isn't.

The reason I don't claim Meltdown is _obviously_ a bug is that it - as commonly defined - isn't one if one looks at speculative execution and the effects on the processor state.

There are two types of state of a processor:
Architectural state - the state of an instruction set architecture, e.g. register content.
Micro-architectural state - state that isn't directly related to the ISA, e.g. the content of caches.

Meltdown is due to Intel not doing a privilege check enabling speculative user-mode code to access kernel-mode memory. It isn't documented, the official documentation doesn't mention this but say that illegal accesses will cause a protection exception.

Some claim that because Intel rolls back the architectural state after a wrongly done read this isn't a bug and is similar of the Spectre problem.

I (and many others) point out that using cache side-channels is long known to be possible and that their processor doesn't follow the documented behavior: it in some cases allow an user-mode process to read kernel-mode memory with all the known side-effects even if the architectural state is corrected.

In comparison Spectre doesn't skip anything, the processor is acting exactly as it is described to do. This includes speculation and how it affects micro-architectural state.


This issue seems to have taken the tech community by surprise, needs to be addressed as quickly as possible due to the severity and is challenging to fix.


It is a serious problem. The best thing would be if the industry as a whole would co-operate in making processors protected against such attack.

Will not happen. ;)

Reply Parent Score: 2