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.

Order by: Score:
No solution
by Treza on Tue 30th Jan 2018 00:29 UTC
Treza
Member since:
2006-01-11

After being aware of the issue for 6 months, it seems now clear that either there is no microcode solution able to solve the problem, or the solution would compromise performances so much that Intel would have to pay back customers.

I'm afraid that Intel won't really fix the issue in current chips, a bit like with the old Pentium FDIV bug, they will insist, at first, that it won't be a real problem in most situations.

Reply Score: 8

RE: No solution
by dionicio on Tue 30th Jan 2018 00:39 UTC in reply to "No solution"
dionicio Member since:
2006-07-12

Could Be Worst, Treza. At this moment wouldn't like to consider the possibility of the breach allowing micro-code corruption.

Reply Score: 1

RE: No solution
by Megol on Tue 30th Jan 2018 14:12 UTC in reply to "No solution"
Megol Member since:
2011-04-11

After being aware of the issue for 6 months, it seems now clear that either there is no microcode solution able to solve the problem, or the solution would compromise performances so much that Intel would have to pay back customers.

I'm afraid that Intel won't really fix the issue in current chips, a bit like with the old Pentium FDIV bug, they will insist, at first, that it won't be a real problem in most situations.


They can't and they shouldn't. Why?

IT ISN'T A BUG.

The FDIV problem was a bug: optimization of a hardware table that failed for some numbers.

F00F was a bug: failure to detect illegal opcode that meant the hardware could reach a state it shouldn't - resulting in halting execution.

IMO the Meltdown thing is a bug (not all think so).

This isn't. The processor does what it was designed to do, what it is documented to do in a way that is documented. No bug.

And it's an industry wide problem. Problem - not bug.

Reply Score: 2

RE[2]: No solution
by CaptainN- on Tue 30th Jan 2018 15:25 UTC in reply to "RE: No solution"
CaptainN- Member since:
2005-07-07

It's a design flaw, which in software at least, can still be called a bug. It does do what it was designed to do, but due to an oversight, it has a security problem that no one noticed for a long period of time.

Reply Score: 4

RE[2]: No solution
by Treza on Tue 30th Jan 2018 21:16 UTC in reply to "RE: No solution"
Treza Member since:
2006-01-11

The processor does what it was designed to do


Oh, if it is not a bug, I guess it is a feature !

Reply Score: 4

RE[2]: No solution
by viton on Tue 30th Jan 2018 21:50 UTC in reply to "RE: No solution"
viton Member since:
2005-08-09

IMO the Meltdown thing is a bug (not all think so).

This isn't. The processor does what it was designed to do, what it is documented to do in a way that is documented. No bug.


Not sure if you're trolling or not.
Access to high privileged kernel-mode memory from unprivileged usermode process is not documented and it is definitely _not_ a designed behaviour.

Please, show me the description of this "feature" in architecture reference manual.

Edited 2018-01-30 22:05 UTC

Reply Score: 7

RE[3]: No solution
by Megol on Wed 31st Jan 2018 11:17 UTC in reply to "RE[2]: No solution"
Megol Member since:
2011-04-11

"IMO the Meltdown thing is a bug (not all think so).

This isn't. The processor does what it was designed to do, what it is documented to do in a way that is documented. No bug.


Not sure if you're trolling or not.
"

Obviously not trolling. But I know what I'm talking about.


Access to high privileged kernel-mode memory from unprivileged usermode process is not documented and it is definitely _not_ a designed behaviour.


But Spectre doesn't allow that _in_the_way_the_processor_is_defined_.


Please, show me the description of this "feature" in architecture reference manual.


That kernel mode programs can read memory read kernel memory? Download and read:
https://software.intel.com/en-us/articles/intel-sdm

Drill down into the description of how memory protection works.

Reply Score: 3

RE[4]: No solution
by viton on Fri 2nd Feb 2018 03:26 UTC in reply to "RE[3]: No solution"
viton Member since:
2005-08-09

But Spectre doesn't allow that _in_the_way_the_processor_is_defined_.

Spectre v1 and v2 are not breaking protection domains.
The fact that you can establish side channel is irrelevant.

That kernel mode programs can read memory read kernel memory?
User mode programs should not event touch the privileged memory.

AMD (and others) are doing things right.

The AMD microarchitecture does not allow memory references, including speculative references, that access higher privileged data when running in a lesser privileged mode when that access would result in a page fault.

Reply Score: 2

RE[2]: No solution
by aaronb on Wed 31st Jan 2018 13:44 UTC in reply to "RE: No solution"
aaronb Member since:
2005-07-06

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.

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.

Reply Score: 3

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 Score: 2

RE[4]: No solution
by viton on Fri 2nd Feb 2018 03:42 UTC in reply to "RE[3]: No solution"
viton Member since:
2005-08-09

My option is also that Meltdown is a bug

But wasn't it you was you who said No bug? ;)

It isn't documented, the official documentation doesn't mention this but say that illegal accesses will cause a protection exception.

You need memory protection to _prevent unauthorized access_, not to fire-up some exceptions.

Meltdown could be implemented without Spectre-style attack, but with the help of TSX extensions.

Reply Score: 2

Comment by Kroc
by Kroc on Tue 30th Jan 2018 06:09 UTC
Kroc
Member since:
2005-11-10

and then noted that situations like this may result in "data loss or corruption"

The fucking irony

Reply Score: 2

shameful
by codifies on Tue 30th Jan 2018 07:30 UTC
codifies
Member since:
2014-02-14

> This whole thing is a mess.

isn't it just... really its embarrassing, is this industry somehow especially vulnerable to the omnishambles... its a clusterf.....

Reply Score: 1

Fudge
by MarkHughes on Tue 30th Jan 2018 07:35 UTC
MarkHughes
Member since:
2013-11-14

Oh well, At least computers are just a passing fad and nobody needs them for anything much...

(Advice I was given on telling my school careers officer I wanted to be a coder back in the early 90's)

Reply Score: 5

RE: Fudge
by Fergy on Tue 30th Jan 2018 07:39 UTC in reply to "Fudge"
Fergy Member since:
2006-04-10

Oh well, At least computers are just a passing fad and nobody needs them for anything much...

(Advice I was given on telling my school careers officer I wanted to be a coder back in the early 90's)

Could've been a cool story for the 70's but in the 90's this guy should've been kept from all children.

Reply Score: 5

RE[2]: Fudge
by MarkHughes on Tue 30th Jan 2018 10:34 UTC in reply to "RE: Fudge"
MarkHughes Member since:
2013-11-14

"Oh well, At least computers are just a passing fad and nobody needs them for anything much...

(Advice I was given on telling my school careers officer I wanted to be a coder back in the early 90's)

Could've been a cool story for the 70's but in the 90's this guy should've been kept from all children.
"

I 100% agree, He was in his 70's and should have been retired... That's why I became a qualified mechanic and only got into coding professionally 10 years ago. I'm not bitter about it though at all ;)

Reply Score: 3

RE: Fudge
by Treza on Tue 30th Jan 2018 22:35 UTC in reply to "Fudge"
Treza Member since:
2006-01-11

No, it is instead that soon computers will be able to program themselves better than any human coder ;-)

Reply Score: 3

Bugs?
by VERITAS on Tue 30th Jan 2018 09:22 UTC
VERITAS
Member since:
2009-09-14

I am afraid that they opened(implemented) a 'door' they shouldn't...
And the funny thing is that almost all the other CPU's (non Intel) have some how the same feature bug too. ;) Very funny? ;)

Reply Score: 1

IME
by project_2501 on Tue 30th Jan 2018 12:26 UTC
project_2501
Member since:
2006-03-20

Just wait to IME starts to show vulnerabilities...

.. its way more complex (harder to understand and get right).. and the exploits will be extremely difficult to even detect... Because the Intel IME is designed like a spyware platform.

You ain't seen nuffin'yet.

Reply Score: 1

RE: IME
by dionicio on Tue 30th Jan 2018 15:01 UTC in reply to "IME"
dionicio Member since:
2006-07-12

Allow Us NOT to talk UEFI, or any kind of "firm"-ware, at this moment.

Reply Score: 1