

Errata prompt Intel to disable TSX in Haswell, early Broadwell CPUs - geoffgasior
http://techreport.com/news/26911/errata-prompts-intel-to-disable-tsx-in-haswell-early-broadwell-cpus

======
mrb
For those wondering, the TSX instruction set is
[http://en.wikipedia.org/wiki/Transactional_Synchronization_E...](http://en.wikipedia.org/wiki/Transactional_Synchronization_Extensions)

I first heard about transactional memory when Sun had plans to implement it
for its UltraSPARC Rock processor. There is a decent overview of the concept
at
[http://en.wikipedia.org/wiki/Transactional_memory](http://en.wikipedia.org/wiki/Transactional_memory)

~~~
mnarayan01
The techreport.com article says:

    
    
      The obvious initial targets for TSX optimization are server-class applications like transactional database servers.
    

Looking at your wiki links though, I would think this would be awesome for
almost any high-performance multi-threaded program. Am I wrong about that?

~~~
sdab
In theory yes, though thinking in terms of transactions is subtly different
from thinking in terms of threading critical sections. Particularly, they
differ in how they handle contention. Locks block while transactions
abort/fail. Simply retry-ing a transaction is also not a good idea which is
why it is currently suggested to fallback on locks [1]. So I assume the
suggestion of using it for dbs is because it would be more straight-forward as
dbs are already used to transactions.

1\. [https://software.intel.com/en-us/blogs/2013/06/23/tsx-
fallba...](https://software.intel.com/en-us/blogs/2013/06/23/tsx-fallback-
paths)

------
voidlogic
>Software developers who wish to continue working with TSX will have to avoid
updating their systems to newer firmware revisions—and in doing so, they'll
retain the risk of TSX-related memory corruption or crashes.

Say I bought a TSX enabled CPU specifically for that feature, I wonder if
Intel will give me my money back... (they can have their broken CPU of course
too)

~~~
gambiting
Theoretically, yes - I almost returned my laptop with an i7 2630QM CPU, which
should, as indicated on Intel's website, support AES instructions. But the
specific BIOS of that laptop has them disabled and there was no way to re-
enable them. So I contacted the manufacturer, and after a few emails they
agreed that yes, I can return the product as "not as described" but they said
that a new BIOS is also in the works for that laptop and if I am patient it
will be made available soon - and it was, AES instructions were enabled after
a patch issued 2 months later.

~~~
raverbashing
The real question is why does this depend on the BIOS

~~~
mschuster91
In case of AES I guess US crypto export regulations running amok...

~~~
wmf
But all BIOSes and motherboards are made in China.

~~~
mschuster91
If the guys on the label are American, then US regulations apply, too.

Even if not, the US stick their nose anywhere, even where it does not
belong...

------
rayiner
Unsurprising. I don't think the details of TSX have been revealed, but the
implementation potentially has complex interactions with the cache subsystem:
[http://www.realworldtech.com/haswell-
tm](http://www.realworldtech.com/haswell-tm).

Given that TSX is one of the features that distinguishes some of the more
expensive Haswell SKU's, is Intel going to issue a refund for affected
customers?

~~~
wtallis
I've been tempted recently by the _Devil 's Canyon_ repackaging of Haswell
that for the first time has some of the workstation/server features (VT-d,
TSX, but no ECC) enabled on an overclockable model. Losing TSX definitely cuts
down on that temptation a bit, but they've still got the combination of full
virtualization capabilities and much higher single-threaded performance than
anything else out there.

~~~
nullc
Four cores is really not that attractive... also a lack of ECC with the amount
of ram systems have today is starting to seem irresponsible. The probability
of getting bitflips is macroscopic.

~~~
wtallis
I understand that the 4790K isn't really a tradional workstation chip, but
it's definitely the right thing for my workload which involves a simulation
that's only partially multithreaded and would benefit a lot more from higher
single-core speed than it would benefit from more than 4 cores. And ECC would
be nice, but in my opinion isn't a hard requirement yet for all workstation
usage the way it is for servers; I can certainly get by without it, since the
base failure rate of the software I'm using is much larger than that caused by
hardware memory corruption.

------
DSingularity
Yeah, this is exactly why high performance chips have a microarchitecture that
lags client chips. Such bugs would devastate the value of those chips. This
will affect haswell Xeon. I bet some serious discussions for delaying that
chip are ongoing right now.

------
filereaper
Here's the current list of Errata's from June:
[http://www.intel.com/content/dam/www/public/us/en/documents/...](http://www.intel.com/content/dam/www/public/us/en/documents/specification-
updates/4th-gen-core-family-desktop-specification-update.pdf)

I see two about TSX:

    
    
      HSD87 X No Fix          Intel® TSX Instructions May Cause Unpredictable System behavior
      Problem: Under certain system conditions, Intel TSX (Transactional Synchronization Extensions) instructions may result in unpredictable system behavior.
      Implication: Due to this erratum, use of Intel TSX may result in unpredictable behavior.
      Workaround: It is possible for the BIOS to contain a workaround for this erratum.
      Status: For the steppings affected, see the Summary Table of Changes
    
      HSD114 X No Fix         Intel® TSX Instructions May Cause Unpredictable System behavior
      Problem: Under a complex set of internal timing conditions and system events, software using the Intel TSX (Transactional Synchronization Extensions) instructions may observe unpredictable system behavior.
      Implication: This erratum may result in unpredictable system behavior. Intel has not observed this erratum with any commercially available system.
      Workaround: It is possible for the BIOS to contain a workaround for this erratum.
      Status: For the steppings affected, see the Summary Table of Changes
    

HSD114 above seems to be the bug from the techreport article.

------
0x0
So.. will everyone simply accept the microcode update that disables those
instructions? Or will there be some kind of compensation for newer laptops
etc? Wonder how Apple will deal with this, for example.

Or is this such a non-issue that nobody cares?

~~~
exelius
Yes, everyone will accept the microcode update. TSX is still pretty new and I
doubt a lot of code uses it. Intel tends to phase features like this in over a
few generations of CPUs for this reason.

The only real impact is that code that relied on TSX would need to rely on
fallback methods of accomplishing the same tasks. Since there's probably not
much of that floating around, there's very little impact at this time.

~~~
sillysaurus3
How do CPU vendors issue a microcode update such that no hacker could make
their own malicious update? It's obviously a cryptographically signed update,
and the CPU checks that the update is signed by the expected key, but does
that mean every CPU is hardcoded to check for a specific key? What happens if
that key is compromised? Is every CPU at risk forever at that point, or can
the CPU be updated via software to check for a newly issued key? Also, were is
the private key stored? Some vault somewhere? How would a CPU vendor know if
the key had been surreptitiously copied, and some rogue group was issuing
malicious updates to a specific target's CPU?

Is it even advantageous for an attacker to have the capability of issuing
microcode updates to a target computer? What sort of attacks could you mount
via microcode updates?

~~~
0x0
I think they are mostly undocumented, but here is some research I found
online: [http://inertiawar.com/microcode/](http://inertiawar.com/microcode/)

I'm guessing the private RSA keys are extremely well guarded, probably stored
in a HSM that only allows signing, not key extraction, so that the keys cannot
even be revealed to Intel.

On the other hand, who knows. There's certainly been cases of code signing
keys on the loose (Adobe, etc) and even a compromised HSM host (Fedora,
someone managed to sign compromised openssh .rpms)

~~~
exelius
Given that Intel processors largely run the servers that the modern world runs
on, I would expect that the NSA/CIA has done a full security audit of their
microcode processes. The US government is nothing if not thorough about these
types of potential security issues.

~~~
pgeorgi
And in exchange for that audit they gained permission to get their own
microcode updates signed, too?

~~~
amluto
I'm not sure why they'd want it. Unless there's secret non-volatile storage on
Intel chips, there's relatively little of value that you can do using a rogue
microcode update. This is because Intel chips reset to factory microcode when
rebooted.

It's plausible that a rogue microcode update could be used to bypass TPM
static-root-of-trust protections, though, and a microcode update could
certainly bypass TXT's dynamic root of trust. This might enable a bootable USB
stick that would load malicious microcode and then reboot warmly enough to
preserve the microcode and then launch the OS with a TXT bypass.

Even so, I don't really see the point. So far, essentially every BIOS can be
freely (or freely using an exploit) reflashed from kernel mode, and a new
image could contain malicious SMM code, and SMM code can also bypass both
static and dynamic roots of trust.

~~~
pgeorgi
Make RDRAND less random, store AESNI key data in a place you can later
exfiltrate it from, provide SMM capabilities to the current execution context
with some magic opcode (I grant that the latter is easier done through a
malicious firmware update - but that's also easier to detect, since x86 code
is a known format)...

Modulo the microcode signature, flash is better locked down these days: Flash
updates are typically arbitrated by the firmware (though that's also just one
signature away), requiring a reboot, while microcode updates are still free
for all (in ring0 - realtek already lost a driver signing key once, why not
again?).

~~~
amluto
Flash updates arbitrated by firmware? In theory, yes, but in most systems
they're not. [1][2]

[1]
[http://www.syscan.org/index.php/download/get/6e597f6067493dd...](http://www.syscan.org/index.php/download/get/6e597f6067493dd581eed737146f3afb/SyScan2014_CoreyKallenberg_SetupforFailureDefeatingSecureBoot.zip)
[2]
[http://mjg59.dreamwidth.org/30773.html](http://mjg59.dreamwidth.org/30773.html)

~~~
pgeorgi
I have a board normally running UEFI Secure Boot with no flash lock enabled at
all right here on my desk - with UEFI replaced by a sane coreboot
implementation (which locks down flash and SMM memory and signals
unconditionally on boot).

So yes, I'm quite aware of the immense set of faults in UEFI implementations
(some of which are encouraged by UEFI's design, where more layers of UEFI are
added to mitigate them).

But as an attacker I wouldn't want to assume that I run into any single of the
many UEFI implementation quirks and adapt my attack to everyone of them.

And I really hope for Intel that Tianocore won't become an endless stream of
portable UEFI security issues - otherwise the IBVs might get second thoughts
about standardizing on a single codebase.

------
comex
I think this is the latest specification update for at least some of the
relevant processors:

[http://www.intel.com/content/dam/www/public/us/en/documents/...](http://www.intel.com/content/dam/www/public/us/en/documents/specification-
updates/4th-gen-core-family-desktop-specification-update.pdf)

It was last updated in June, so I guess it doesn't contain this latest
erratum. Can't wait until it's updated... though I don't know if Intel is
likely to disclose details.

~~~
yuhong
This one has been updated:
[http://www.intel.com/content/dam/www/public/us/en/documents/...](http://www.intel.com/content/dam/www/public/us/en/documents/specification-
updates/xeon-e3-1200v3-spec-update.pdf)

~~~
EdSharkey
I read through this and found the TSX errata as #136 on a list of 140 issues.
I was pretty surprised; some of these issues are major, showstopper crash bugs
(admittedly mostly only affecting operating systems developers, and many with
workarounds.)

Just reading through these issues, I see a handful that deal with specifically
with external (proprietary?) hardware integrations, like with integrated Intel
graphics boards. Why is the CPU loaded up extra jazz for with specific
integrations like this? Is this to support a system-on-a-chip optional kind of
configuration, or is this Intel trying to give themselves some sort of
advantage in the graphics adapter market?

If it is the latter, then it serves them right to have these errata and
instability due to adding all that extra competitive advantage nonsense on the
chip.

------
sbahra
So, what's the bug exactly?

~~~
sillysaurus3
I get the feeling that few people know, and they're not telling. Maybe to
prevent exploits from being written against the existing CPUs.

------
kps
Dang. I bought an i4770 rather than i4770K specifically because of TSX.

~~~
reitzensteinm
I also did this, missing out on 100mhz of base clock (3.4ghz vs 3.5ghz for the
k).

TSX seemed like a once in a decade step forward, though as I understand it the
restrictions with the cache size (and thus the amount of memory you can write
to before the transaction gets too big) meant it wasn't very practical for
much beyond optimistic lock acquisition.

For example, PyPy isn't planning on doing a TSX port even with their
enthusiasm for transactional memory.

Also influencing my decision, I bought a 2600k a few years back, but never
bothered overclocking it, which I guess was an admission that the excitement I
found for hardware when I was a child was dead. I guess you either have the
money, or the time, but rarely both.

It's disappointing that this microcode update isn't being done in such a way
that you can re-enable it after agreeing to a disclaimer that it's not for
production use. I'm not sure what the mechanism for this would look like, but
given that Intel sold cards that unlocked Hyperthreading, I'm sure it's
possible.

[http://www.engadget.com/2010/09/18/intel-wants-to-
charge-50-...](http://www.engadget.com/2010/09/18/intel-wants-to-charge-50-to-
unlock-stuff-your-cpu-can-already-d/)

Edit: The article has been updated saying that it will be possible to enable
TSX for development purposes on Haswell-EP at least.

~~~
ak217
> For example, PyPy isn't planning on doing a TSX port even with their
> enthusiasm for transactional memory.

Do you have more information about their reasoning behind this? From my point
of view this is the highest profile software project to potentially make use
of HTM, and I recall reading that the plan was to eventually introduce
hardware acceleration.

~~~
sounds
In reference to the sibling post that gives more details about pypy, I'd like
to call to your mind the history of the vector extensions for x86.

First revision: MMX. It reused the same registers as the older x87 floating
point coprocessor (even though the x87 transistors lived on the same die). As
a result, legacy x87 code and MMX code had to transition using an expensive
EMMS instruction.

Second revision: (well, ignoring some small changes to MMX) ... SSE. Finally
got its own registers, but lacked a lot of real-world capability.

Third revision: SSE2, finally got to a level of parity with competing vector
extensions (see, for example, PowerPC's Altivec).

And so forth.

I guess the take-home lesson for me is that these new TSX instructions are
indeed fascinating to play around with, but I wouldn't expect it to blow the
doors off. Intel will incrementally refine it.

(The incremental approach also gives Intel a chance to study how it's being
used and keeps AMD playing catch-up.)

~~~
MBCook
The other big problem with MMX was that it was integer only. While that might
have been ok for some application 3D games and other software that could
really use the boost needed floating point and not only couldn't benefit
(since it was integer only) it actually interfered (since, as you said, it
reused the registers).

AMD's 3DNow had single precision floating point support, so it was actually
somewhat useful. SSE followed 3DNow and added single precision support (as
well as fixing the register stuff). SSE2 added double precision support.

~~~
sounds
Right, thanks for those additional details.

Today, no one would use MMX instructions (since SSE is vastly superior). I
expect Intel will continue to add TSX capabilities which will eventually
produce some nice results for parallel code.

------
Firefishy
Running a recent Ubuntu or Debian?

Install the microcode by running: sudo apt-get install intel-microcode

Alternatively install a BIOS update once available.

~~~
codemac
sudo pacman -S intel-ucode

------
monocasa
That's too bad, I was really looking forward to playing around with TSX on
some side projects.

------
ksec
Well they should consider themselves fortunate since Haswell Xeon isn't yet on
the market.

Are there any scenario where Transactional Memory are useful in consumer
environment?

~~~
sounds
Mostly for developers to start testing their code.

