Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Understanding L1 Terminal Fault aka Foreshadow: What You Need to Know

redhat.com

Post reply on HN
Print view View original

91–100 of 119 posts

Re: Understanding L1 Terminal Fault aka Foreshadow: What You Need to Know

#91

Post by gaius »

rurban wrote: post #78
gaius wrote: post #27

Earlier quoted context omitted.

The closest alternative would be ARM On the contrary there's SPARC, MIPS, PA-RISC, POWER and a whole heap of others that perhaps were written off prematurely. Need to move quickly tho' while some vestiges of expertise still remain.

Sparc, Tilera and Parallela are unfortunately gone. I had high hopes into the latter two, esp. since Grid CPU's are perfect for machine learning. Much better than GPU's.

Fujitsu still have SPARC on their roadmap http://www.fujitsu.com/global/products/computing/servers/uni...

Re: Understanding L1 Terminal Fault aka Foreshadow: What You Need to Know

#92

Post by repolfx »

classichasclass wrote: post #8
blinkingled wrote: post #4

Earlier quoted context omitted.

Move where exactly? At this point x86 is the least of all evils that have respectable performance.

And this is why computing monocultures are bad, because the dominant architecture may have painted itself into a corner. That's why alternatives like Open POWER are important.

No, these sorts of faults can occur in any high performance chip. Intel is bearing the brunt only because they're the fastest. But Meltdown also affected an Apple core if I recall correctly and Spectre nailed them all.

This isn't as simple as "Intel/x86 sucks, let's go use SPARC". The causes run much deeper and the necessary fixes may or may not be architecturally elegant or simple.

Re: Understanding L1 Terminal Fault aka Foreshadow: What You Need to Know

#93

Post by geogriffin »

zimmerfrei wrote: post #83
bscphil wrote: post #79

Earlier quoted context omitted.

Isn't this pretty much a no-go for any large public software project, given that microcode updates often depend on the OEMs, which are notoriously bad about supporting devices older than about a year?

I think that is mostly the case for BIOS and platform firmware. CPU microcode can be loaded by the OS (if the OS allows you to, as Linux does - https://www.cyberciti.biz/faq/install-update-intel-microcode... ).

BIOS updates are required for most SGX-related microcode updates, as the microcode has to be up-to-date before enabling the SGX feature via a MSR (which is usually done by the BIOS). This is so you can't start an enclave with old microcode, exploit it, upgrade microcode, and still pass remote attestation.

Also, the more major spectre-related microcode updates have to be applied very early (in the BIOS) probably for technical reasons. For this latest microcode update, for example, Intel didn't even include it in their downloadable microcode package as you linked to. On my v6 Xeons, I was able to get to revision 0x84 with the latest OS microcode package, but 0x8e with a BIOS upgrade.

Re: Understanding L1 Terminal Fault aka Foreshadow: What You Need to Know

#94

Post by geogriffin »

bscphil wrote: post #79
geogriffin wrote: post #59

Earlier quoted context omitted.

SGX Remote Attestation was built specifically to deal with events like this. Intel starts to reject attesting to vulnerable microcode revisions after some period following disclosure. In this case, they even postponed disclosure until patched microcode revisions were available and those revisions already required for successful attesation. If said SGX application wasn't built around this model then it's probably not…

Isn't this pretty much a no-go for any large public software project, given that microcode updates often depend on the OEMs, which are notoriously bad about supporting devices older than about a year?

It looks like Intel is pushing these security-related patches pretty hard on vendors, as this latest patch was available in late May on one IBM board Softlayer uses, and early June on another Supermicro board they use.

Re: Understanding L1 Terminal Fault aka Foreshadow: What You Need to Know

#95

Post by geogriffin »

zimmerfrei wrote: post #86
lvh wrote: post #41

This is _bananas_. - Unlike previous speculative execution attacks against SGX, this extracts memory "in parallel" to SGX, instead of attacking the code running in SGX directly. It always works: it doesn't require the SGX code to run and it doesn't require it to have any particular speculative execuction vulnerability. This also means existing mitigations like retpolines don't work. - It lets you extract the sealing…

>> - It lets you extract the sealing key and remote attestation. That's about as bad as it gets. It could have definitely been worse, with the leak of the fused secrets or a breach to integrity of the microcode (the two things that together constitute the TCB, which put simply is the only piece of the system you assume will never be broken). All in all, assuming a microcode update can counter the attack as Intel clai…

Agreed.

> Only the CPU (silicon or microcode) can assist you in the flushing of L1 when you exit enclave mode.

This seems correct, upon double-checking. The interrupt process within SGX is called Asynchronous Enclave Exit (AEX) and does not give the enclave an opportunity to run any code upon interrupt, though it is possible to run code upon every enclave entry (via code placed at the Asynchronous Entry Pointer). I'm not sure that would help with any speculation-based exploits, however.

Re: Understanding L1 Terminal Fault aka Foreshadow: What You Need to Know

#96

Post by theandrewbailey »

pbourke wrote: post #73
theandrewbailey wrote: post #12

Earlier quoted context omitted.

I upgraded from an i7-2600 to an 1800X over a year ago. Once the memory issues were solved (running at 3200 MHz vs ~2800 MHz), I've been happy with my purchase.

I just went from i5-3750K to Ryzen 2700X and had a similar issue getting to the advertised memory frequency. Looks like it’s par for the course and will get sorted out in due time. I’m happy with the AMD CPU outside of that one problem.

I recall that the big (last) problem was setting the command rate to 2T. I eventually figured out that my ASUS board had a "geardown mode" enabled that always forced 1T, so I turned that off and I've been at full speed since. Not sure if this will help you.

Re: Understanding L1 Terminal Fault aka Foreshadow: What You Need to Know

#97

Post by IanSanders »

hexane360 wrote: post #87
wlll wrote: post #6

Earlier quoted context omitted.

I'm seriously thinking about getting an AMD CPU for my desktop when this i7 4770k finally needs replacing.

OTOH it seems like all the major cloud providers are still happy using Intel. They probably have a pretty good reason to do so.

Unfortunately AMD is not doing well in the server market at the moment (last time I looked into it)

Re: Understanding L1 Terminal Fault aka Foreshadow: What You Need to Know

#98

Post by xenophonf »

DerSaidin wrote: post #21
blinkingled wrote: post #4

Earlier quoted context omitted.

Move where exactly? At this point x86 is the least of all evils that have respectable performance.

https://millcomputing.com ?

Last I checked, the Mill is vaporware. They have some interesting patents, a private simulator, parts of a compiler toolchain, and that's it. At least with OpenPOWER and RISC V, you can buy processors and even complete systems.

Re: Understanding L1 Terminal Fault aka Foreshadow: What You Need to Know

#99

Post by wlll »

hexane360 wrote: post #87
wlll wrote: post #6

Earlier quoted context omitted.

I'm seriously thinking about getting an AMD CPU for my desktop when this i7 4770k finally needs replacing.

OTOH it seems like all the major cloud providers are still happy using Intel. They probably have a pretty good reason to do so.

It's something of a self fulfilling prophecy I suspect. People use Intel because people use Intel. "Nobody got fired for buying IBM" etc.

As a sysadmin (who admittedly doesn't deal with hardware much) these issues with Intel chips (the mitigation of which can seriously decrease performance), and the relative ease with which AMD has come through the problems make me wonder if we would be better with AMD.

I'm reminded of this experiment:

https://www.dowellwebtools.com/tools/lp/Bo/psyched/16/Smoke-...

"People respond slower (or not at all) to emergency situations in the presence of passive others."

Re: Understanding L1 Terminal Fault aka Foreshadow: What You Need to Know

#100

Post by wlll »

theandrewbailey wrote: post #12
wlll wrote: post #6

Earlier quoted context omitted.

I'm seriously thinking about getting an AMD CPU for my desktop when this i7 4770k finally needs replacing.

I upgraded from an i7-2600 to an 1800X over a year ago. Once the memory issues were solved (running at 3200 MHz vs ~2800 MHz), I've been happy with my purchase.

What was the memory problem specifically, and how did you solve it, if you don't mind going into that?
Post reply on HN