Intel exploit

[Viditor]

Cnet

"If a hacker can use this new exploit to embed a SMM rootkit (malware) they would have ultimate control over the box (computer). Additionally, it would be virtually undetectable," Heary wrote in response to an e-mail query. But he also added: "In a nutshell. This exploit is very serious and needs to fixed. But...I don't see a mass virus or worm using this. The attacks will be targeted. A rootkit must be perfectly matched to the hardware. This makes mass infection more difficult." "

"And what systems are potentially vulnerable? Though both Intel and Rutkowska say the "attack" presented in the paper has been fixed on some systems, Rutkowska goes on to say: "We have however found out that even the relatively new boards, e.g. Intel DQ35 are still vulnerable (the very recent Intel DQ45 doesn't seem to be vulnerable though). The exploit attached is for DQ35 board--the offsets would have to be changed to work on other boards (please do not ask how to do this)." (Here is a list of Intel motherboards she refers to.) "

 

[taltamir]

Then there's the whopper of them all--and a flaw very different in nature from the SMM vulnerability discussed above--the show-stopping 1994 Intel FDIV bug, discovered by Professor Thomas Nicely, then at Lynchburg College in Virginia. Also referred to as the floating-point bug, it wasn't a flaw exploitable by malicious hackers; rather, it was a bug in Intel's original Pentium floating-point unit. Certain arcane floating-point division operations done on these processors would generate incorrect results.
This bug, covered prominently by The New York Times and CNN at the time, actually had virtually no affect on users, except causing them to panic and, as a consequence, some insisted that Intel provide them with new processors. The recall cost Intel close to a half-billion dollars.

This entirely article makes light of defective hardware, which is BS.
"arcane floating point operation" sounds very buzz wordish, but if you know floating point means "decimal math" (instead of integer math) than giving a wrong result is catastrophic.

But the part where the guy says its not gonna be in a virus wasn't written by inept cnet "reporters" but by the security expert who FOUND the bug in question. So that is probably true.

 

[zagood]

http://forums.anandtech.com/me...=2287470&enterthread=y

http://forums.anandtech.com/me...=2287112&enterthread=y

 

[Idontcare]

Originally posted by: taltamir

Then there's the whopper of them all--and a flaw very different in nature from the SMM vulnerability discussed above--the show-stopping 1994 Intel FDIV bug, discovered by Professor Thomas Nicely, then at Lynchburg College in Virginia. Also referred to as the floating-point bug, it wasn't a flaw exploitable by malicious hackers; rather, it was a bug in Intel's original Pentium floating-point unit. Certain arcane floating-point division operations done on these processors would generate incorrect results.
This bug, covered prominently by The New York Times and CNN at the time, actually had virtually no affect on users, except causing them to panic and, as a consequence, some insisted that Intel provide them with new processors. The recall cost Intel close to a half-billion dollars.

This entirely article makes light of defective hardware, which is BS.
"arcane floating point operation" sounds very buzz wordish, but if you know floating point means "decimal math" (instead of integer math) than giving a wrong result is catastrophic.

But the part where the guy says its not gonna be in a virus wasn't written by inept cnet "reporters" but by the security expert who FOUND the bug in question. So that is probably true.

The "arcane" comment is there because it only involves floating point division...the vast majority of floating point calcs are converted to multiplication because division instructions take significantly more execution time than multiplication.

Division itself is not arcane, but finding applications that actually used FP division instead of FP multiplication was pretty rare because of the computational time penalty involved.

http://en.wikipedia.org/wiki/F..._arithmetic_operations

http://en.wikipedia.org/wiki/Division_(digital)

Of particular interest see http://en.wikipedia.org/wiki/H...plication_and_division and note the comment:

Alternatively, Horner's scheme can be computed with n fused multiply-adds

(think about Sandy Bridge and Bulldozer)

On my Q6600 chip, the instruction latency for an x87 multiply is 1.75 clocks whereas the instruction latency for an x87 divide is 17 clocks. Nearly an order of magnitude slower for division. So even if I do division by way of an iterative multiplication technique (links above) provided I get my answer in less than ten (10) successive multiplication computations I will get my answer in less time.

Hence most programs are written to take advantage of FMUL instead of FDIV and it is was (and is) rare to find an application that brute forces division by way of executing FDIV instructions. Ergo the use of the descriptor "arcane" by the author (IMO of course, I'm not 100% positive this was their motivation)

Inst 579 X87 : FMUL st(i), st (st = 0.0) L: 1.51ns= 5.0c T: 0.53ns= 1.75c

Inst 584 X87 : FDIV32 st(i), st L: 5.45ns= 18.0c T: 5.15ns= 17.00c

 

[nyker96]

sounds interesting, but somehow I doubt it will be a wide spread problem.

 

[taltamir]

it allows someone to make a custom tailor made rootkit that only works in your exact hardware configuration and takes over your system... sounds useful for for targeted operations! OMFG ITS THE CIA! [p

 

[dmens]

Originally posted by: Idontcare
The "arcane" comment is there because it only involves floating point division...the vast majority of floating point calcs are converted to multiplication because division instructions take significantly more execution time than multiplication.

Division itself is not arcane, but finding applications that actually used FP division instead of FP multiplication was pretty rare because of the computational time penalty involved.

http://en.wikipedia.org/wiki/F..._arithmetic_operations

http://en.wikipedia.org/wiki/Division_(digital)

Of particular interest see http://en.wikipedia.org/wiki/H...plication_and_division and note the comment:

Alternatively, Horner's scheme can be computed with n fused multiply-adds

(think about Sandy Bridge and Bulldozer)

On my Q6600 chip, the instruction latency for an x87 multiply is 1.75 clocks whereas the instruction latency for an x87 divide is 17 clocks. Nearly an order of magnitude slower for division. So even if I do division by way of an iterative multiplication technique (links above) provided I get my answer in less than ten (10) successive multiplication computations I will get my answer in less time.

Hence most programs are written to take advantage of FMUL instead of FDIV and it is was (and is) rare to find an application that brute forces division by way of executing FDIV instructions. Ergo the use of the descriptor "arcane" by the author (IMO of course, I'm not 100% positive this was their motivation)

Inst 579 X87 : FMUL st(i), st (st = 0.0) L: 1.51ns= 5.0c T: 0.53ns= 1.75c

Inst 584 X87 : FDIV32 st(i), st L: 5.45ns= 18.0c T: 5.15ns= 17.00c

sorry stupid nitpick, the method described is not ULP accurate, whereas FDIV is fully accurate.

in usage models where accuracy can be sacrificed, hardware lookup tables of 1/x are utilized, such that it is significantly faster than a software algorithm. for example, afaik dx10/dx11 requires 0.5 ULP on 32 bit floating divides so the optimal hardware solution would avoid using the traditional iterative divider.

lastly, i think you got the instruction latencies wrong... i think FMUL is 3 and FDIV can be 6, 11 or 32 depending on the source data. yet another stupid nitpick

 

[Idontcare]

Originally posted by: dmens
lastly, i think you got the instruction latencies wrong... i think FMUL is 3 and FDIV can be 6, 11 or 32 depending on the source data. yet another stupid nitpick

It's not stupid if its wrong, I need to know this.

The latency data are extracted with Everest, which performs an instruction level latency measure on the rig (not just pulled from a database). If Everest is making incorrect measurements then folks need to know.

This is from another thread: (pasting for my own ease instead of retyping)

Originally posted by: Idontcare
I should have linked to the following for instructions on how to get Everest to do an instruction latency dump: (its not intuitively obvious from driving thru the standard menu options)

These lists were created by Lavalys EVEREST Instruction Latency dump feature. If you do not believe in software measurements, wait for the official Intel/AMD/etc. guide and hope it will be more detailed and accurate than the current one.

You can create such dump in EVEREST by right-clicking on the bottom status bar of EVEREST main window -> CPU Debug -> Instruction Latency Dump.

It fully works on trial version, too. x64 dumps are based on an unreleased developer x64 EVEREST version.

http://instlatx64.fw.hu/

I took it at face value and assumed the latency dumps would be correct, but I am no expert.

If you've the time to download Everest and poke around with their latency test (maybe scan the documentation with a view for what could cause errant results) then I'd sure appreciate hearing your take on the program.

I thought it was a nifty utility as it exposes what the chip sitting in my system post microcode patchup is capable of doing, as we know microcodes for bug fixes are usually not instruction-level latency reduction activities.

 

[dmens]

looks like we both missed a couple things. L and T stand for latency and throughput... we're only interested in latency.

573 X87 :FMUL st(i), st (st = 0.0) L: 1.87ns= 5.0c T: 0.66ns= 1.75c
576 X87 :FMUL + FADD st, st(i) L: 3.00ns= 8.0c T: [not enough reg]
578 X87 :FDIV32 st(i), st L: 6.74ns= 18.0c T: 6.37ns= 17.00c
579 X87 :FDIV64 st(i), st L: 11.99ns= 32.0c T: 11.61ns= 31.00c
580 X87 :FDIV80 st(i), st L: 14.23ns= 38.0c T: 13.86ns= 37.00c

The table is correct. FMUL is 5. FADD is 3. I got it backwards. doh.

about FDIV, everest uses the following method:

These values are measured by long chains of instructions (~6000), so these are the sustained rates, peak values can be higher.

FDIV on C2D is variable latency based on operand conditions. The instruction stream can contain any combination of those conditions. i don't know how everest comes up with the operands but it did get the 32 cycle latency correct for double precision, which is the vast majority of cases. the lower latencies are special cases. extended precision might be more than 1 instruction. my guess for single precision is the hardware can figure out when there is no work left to do. not my area of knowledge, unfortunately.

 

[Idontcare]

Hey I can settle for us being 0 for 2 :laugh: :thumbsup:

If I am doing the division correctly, I figure that puts us right around a 0.5 batting average

Thanks for checking it out, uncovering the error in my ways, as well as giving the program itself some credence and added validity to its results. That is priceless help right there :thumbsup:

 

[DrMrLordX]

Originally posted by: taltamir
it allows someone to make a custom tailor made rootkit that only works in your exact hardware configuration and takes over your system... sounds useful for for targeted operations! OMFG ITS THE CIA! [p

Shades of the Lone Gunmen there man. Plug in the Octium processor and they compromise your cookies! Oh noes1!11!!11!

Seriously though I see this as being a potential followup payload to a more generic trojan that exploits an OS flaw. Gain control of the machine, gather system specs, automatically build a rootkit based on the Intel SMM flaw, then kerpow. I'm sure it would be more complicated than that but still, it could probably be done.

 

[Idontcare]

Originally posted by: DrMrLordX

Originally posted by: taltamir
it allows someone to make a custom tailor made rootkit that only works in your exact hardware configuration and takes over your system... sounds useful for for targeted operations! OMFG ITS THE CIA! [p

Shades of the Lone Gunmen there man. Plug in the Octium processor and they compromise your cookies! Oh noes1!11!!11!

Seriously though I see this as being a potential followup payload to a more generic trojan that exploits an OS flaw. Gain control of the machine, gather system specs, automatically build a rootkit based on the Intel SMM flaw, then kerpow. I'm sure it would be more complicated than that but still, it could probably be done.

Intel probably intentionally built-in this backdoor so they could silently seize control of all the CPU's they are selling with the goal of enslaving the computing resources as they need the cycles to perform their computational lithography for the 22nm node :laugh:

[insert mandatory sarcasm disclaimer] I am being sarcastic folks, no flames please [/insert mandatory sarcasm disclaimer]

 

[Martimus]

Is this exploit fixed in the i7? It seems like this will cause us to scrap all of our affected computers and update them; perhaps with AMD procesors.

I read through some of the proof of concept, but I did not understand how to actually get "infected" code on your system. It is a little (probably a lot) over my head on explaining that. I am trying to figure out how to protect myself and my coworkers from such an attack.

 

[aigomorla]

Originally posted by: Martimus
Is this exploit fixed in the i7? It seems like this will cause us to scrap all of our affected computers and update them; perhaps with AMD procesors.

you think microsoft would allow something like this when most of the computers in the world are by intel and microsoft?

If not fixed by intel, most defintely microsoft will think of a way to block it.

Shiet they have a habit of blocking things you dont want blocked.

 

[Martimus]

Originally posted by: aigomorla
you think microsoft would allow something like this when most of the computers in the world are by intel and microsoft?

If not fixed by intel, most defintely microsoft will think of a way to block it.

Shiet they have a habit of blocking things you dont want blocked.

I don't have control over what Microsoft does. I just want to understand the possible ways of having my computer infected by this exploit. It is important to avoid this in my line of work.

 

[Phynaz]

Originally posted by: Martimus

Originally posted by: aigomorla
you think microsoft would allow something like this when most of the computers in the world are by intel and microsoft?

If not fixed by intel, most defintely microsoft will think of a way to block it.

Shiet they have a habit of blocking things you dont want blocked.

I don't have control over what Microsoft does. I just want to understand the possible ways of having my computer infected by this exploit. It is important to avoid this in my line of work.

Let a stranger flash your BIOS, that's about the only way.

 

[zsdersw]

Viditor is desperate for some anti-Intel news, I see.

 

[Idontcare]

Originally posted by: zsdersw
Viditor is desperate for some anti-Intel news, I see.

Viditor's action of creating this thread and bringing the subject matter to the forefront of my radar-screen is value-add to me, and from the responses in this thread it sounds like it has brought value to others as well.

I'm not sure what value your post is bringing to anyone here, but I am hoping it was merely meant in jest on your behalf and my sarcasm meter is simply broken...

edit: grammar was unintelligible, hopefully less so now.

 

[DrMrLordX]

Originally posted by: Idontcare


Intel probably intentionally built-in this backdoor so they could silently seize control of all the CPU's they are selling with the goal of enslaving the computing resources as they need the cycles to perform their computational lithography for the 22nm node :laugh:

[insert mandatory sarcasm disclaimer] I am being sarcastic folks, no flames please [/insert mandatory sarcasm disclaimer]

The Israeli design teams slipped in this little backdoor during the design process so that the Mossad could assassinate your Maple Story character without anyone being the wiser.

Of course if you are married to an estranged Japanese woman then the Mossad need not get involved.

 

[DrMrLordX]

double post argh this was supposed to be an edit

 

[Fox5]

Err, so if FMUL can do the same thing as FDIV but faster, why doesn't the FDIV instruction just map to the FMUL hardware?

 

[Idontcare]

Originally posted by: Fox5
Err, so if FMUL can do the same thing as FDIV but faster, why doesn't the FDIV instruction just map to the FMUL hardware?

The iterative routines for FMUL'ing your way to FDIV equivalent involves rounding errors, hence the user (coder) has to specify how many loops they want to execute for their algorithm.

My understanding is that it is a "practical versus technical" situation.

If you want the technically correct answer (to machine precision for the given bits) then you FDIV, if you are interested in just the practical answer which is accurate to a given number of decimal places (maybe you only need to know Pi/4 to 16 decimal places) then you might just FMUL your code to iterate thru Horner's scheme and be done faster.

I know in C programming that computing X*0.1 is significantly faster than computing X/10., at least 3x faster (or more) in my tests. I convert all my divisions to equivalent multiplications where possible.

 

[zsdersw]

Originally posted by: Idontcare

Originally posted by: zsdersw
Viditor is desperate for some anti-Intel news, I see.

Viditor's action of creating this thread and bringing the subject matter to the forefront of my radar-screen is value-add to me, and from the responses in this thread it sounds like it has brought value to others as well.

I'm not sure what value your post is bringing to anyone here, but I am hoping it was merely meant in jest on your behalf and my sarcasm meter is simply broken...

edit: grammar was unintelligible, hopefully less so now.

Of course it was in jest.. hence the smiley.

 

[Idontcare]

Originally posted by: zsdersw

Originally posted by: Idontcare

Originally posted by: zsdersw
Viditor is desperate for some anti-Intel news, I see.

Viditor's action of creating this thread and bringing the subject matter to the forefront of my radar-screen is value-add to me, and from the responses in this thread it sounds like it has brought value to others as well.

I'm not sure what value your post is bringing to anyone here, but I am hoping it was merely meant in jest on your behalf and my sarcasm meter is simply broken...

edit: grammar was unintelligible, hopefully less so now.

Of course it was in jest.. hence the smiley.

Cool, time to go shopping at Target for some replacement batteries for my sarcasm detector!