Intel CPU Design Flaw

lazjen (Chris) · #1 03-01-2018, 11:42 AM

https://www.theregister.co.uk/2018/0...u_design_flaw/

This is pretty significant and could have a negative impact on a number of things we do, e.g. image processing.

If you're looking to build a new system right now, I would pause and/or strongly consider going AMD instead.

RickS (Rick) · #2 03-01-2018, 11:48 AM

I just saw that, Chris. I'm feeling very smug about the AMD Threadripper system I ordered a few days ago

lazjen (Chris) · #3 03-01-2018, 12:14 PM

Cool - spill the beans on the specs, Rick - what are you getting and am I right to assume this will be a PI processing beast?

RickS (Rick) · #4 03-01-2018, 12:26 PM

Quote:

Originally Posted by lazjen

Cool - spill the beans on the specs, Rick - what are you getting and am I right to assume this will be a PI processing beast?

Yep, it's intended to provide scorching PI performance, Chris. CPU is a Threadripper 1950X 16-Core. 64GB DDR4 3600MHz RAM. 500GB NVMe SSD and 10TB HDD. Quadro P2000 graphics.

I have heard anecdotally that PI runs faster under Linux than Windows, so I'll do some comparative benchmarking and do my processing under Linux if it has a measurable advantage.

My current workstation has lasted me 7 years so I thought it was time for a significant upgrade!

Cheers,
Rick.

lazjen (Chris) · #5 03-01-2018, 12:43 PM

I have directly compared PI for Linux vs Windows on the same system - dual boot. And it's definitely better under Linux. I didn't have all variables locked down 100%, but I did notice the difference.

RickS (Rick) · #6 03-01-2018, 12:55 PM

Quote:

Originally Posted by lazjen

I have directly compared PI for Linux vs Windows on the same system - dual boot. And it's definitely better under Linux. I didn't have all variables locked down 100%, but I did notice the difference.

Great, thanks Chris. I'd guess it is mostly down to file system performance. Raw multithreaded processing in user space should be much the same.

gary · #7 03-01-2018, 02:54 PM

Hi Chris,

Thanks for the heads-up.

Not a good way for the world to begin 2018.

Sounds like it has the potential for being the biggest computer vulnerability of all-time.

Given perhaps 1.3 billion machines or more might be vulnerable worldwide and given not all
will have their CPU's replaced or get a software patch, the potential for system breaches, information theft or serious
cyber attacks is mind-boggling.

It is not a question of if it has been exploited, it is now a question of how
many systems have been exploited already.

Camelopardalis (Dunk) · #8 03-01-2018, 02:55 PM

Sounds like someone at Intel was a naughty boy...nothing quite like trading off security for performance

RickS (Rick) · #9 03-01-2018, 03:19 PM

Quote:

Originally Posted by gary

Sounds like it has the potential for being the biggest computer vulnerability of all-time.

At least it's not a remote exploit, Gary, but it could be very ugly. It will certainly be very disruptive.

Quote:

Originally Posted by Camelopardalis

Sounds like someone at Intel was a naughty boy...nothing quite like trading off security for performance

Hard to tell until details are released (or leaked) but it's usually safer to assume incompetence rather than malice

Not thinking through the security implications of speculative execution would be an easy mistake to make.

lazjen (Chris) · #10 03-01-2018, 04:19 PM

It's probably unlikely to get many exploits as fixes will come through, but it's the impact of the fixes that will be the bigger issue.

If we start seeing stuff performing significantly worse after the fix, there will be some screaming. I've been reading reports of some software that have had up to 63% performance loss due to the change. Obviously it depends on the software and what people do, but if it hits something common like web browsers, media players, etc. then stuff might hit the fan...

gary · #11 03-01-2018, 05:49 PM

Quote:

Originally Posted by lazjen

It's probably unlikely to get many exploits as fixes will come through, but it's the impact of the fixes that will be the bigger issue.

If we start seeing stuff performing significantly worse after the fix, there will be some screaming. I've been reading reports of some software that have had up to 63% performance loss due to the change. Obviously it depends on the software and what people do, but if it hits something common like web browsers, media players, etc. then stuff might hit the fan...

Every system call for a start.

Currently in Linux the kernel MMU page tables are mmap'ed so when
you do the context switch, they are just there and its all fast.

But the Linux patches are showing the TLB's are now having to be
flushed on each system call or each interrupt.

So for a start, anything doing lots of I/O will suffer.

Quote:

Originally Posted by Rick

At least it's not a remote exploit, Gary, but it could be very ugly. It will certainly be very disruptive.

Happy New Year Rick. Hope all is well.

True. But from what I can see is if there is some other buffer overrun
exploit in a web browser, you might use this flaw in combination with
that as part of a side-channel attack through some JavaScript.
See https://www.youtube.com/watch?v=ewe3-mUku94

The NSA, the Russians, the Chinese and the North Koreans will be busy.

luka · #12 03-01-2018, 06:02 PM

Quote:

Originally Posted by gary

The NSA, the Russians, the Chinese and the North Koreans will be busy.

I would not be surprised if they knew about the flaw for years and have been exploiting it.

gary · #13 03-01-2018, 06:25 PM

Quote:

Originally Posted by luka

I would not be surprised if they knew about the flaw for years and have been exploiting it.

Absolutely.

lazjen (Chris) · #14 03-01-2018, 09:49 PM

This issue has been publicly known since sometime in 2016. It's implications weren't fully understood at the time. So, I also won't be surprised if it's been known for a lot longer than that.

luka · #15 03-01-2018, 11:08 PM

By the way, ARM64 is also affected (not AMD64).

RickS (Rick) · #16 04-01-2018, 07:52 AM

Quote:

Originally Posted by luka

By the way, ARM64 is also affected (not AMD64).

Do you have a link?

RickS (Rick) · #17 04-01-2018, 08:02 AM

Quote:

Originally Posted by RickS

Do you have a link?

Found a recent arm64 patch that unmaps the kernel while running in user space: https://lwn.net/Articles/740393/

It is based on the paper here: https://gruss.cc/files/kaiser.pdf

It looks like this is a general response to the problem of kernel bugs, Rowhammer attacks, etc. and not a reaction to a specific vulnerability. But I could be wrong. The details of the x86 problem have been kept very much under wraps.

Update: here's a 2016 paper that appears to describe the vulnerability: https://gruss.cc/files/prefetch.pdf

lazjen (Chris) · #18 04-01-2018, 11:21 AM

More gory details: https://spectreattack.com/

I haven't gone through it all, a brief skim is enough to know it's bad...

gary · #19 04-01-2018, 12:26 PM

Rick, Chris,

Thanks for the links to the papers and other references.

One certainly gets the impression that there is a scramble to implement
Linux Kernel Page Table Isolation (was KAISER) and one can only assume
kernel programmers at Microsoft and Apple have been hard at it as well.

Probably no Christmas holiday break for some.

The urgency gives some merit to the prospect that exploits are already in the
wild today, not just on paper.

Specifically the vulnerability surrounding speculative execution to avoid
pipeline stalls may have been knowingly actively exploited (i.e. implementations
of Meltdown and Spectre) leading to the rush.

Let's face it. If the likes of the NSA had not done it years ago, they would have
poured enormous resources into implementing exploits during the past year.

As one of the papers cited tests on smartphones as well as servers, that
represents billions of devices.

The additional clock cycles that will be required for interrupt service routines
is unfortunate. You really just want to get in and out of those handlers as fast
as possible whilst doing the minimum you have to do.

Certainly the performance counters have unwittingly become tools for
exploiting other hardware and software security mechanisms.

Camelopardalis (Dunk) · #20 04-01-2018, 12:38 PM

Quote:

Originally Posted by RickS

Hard to tell until details are released (or leaked) but it's usually safer to assume incompetence rather than malice

Not thinking through the security implications of speculative execution would be an easy mistake to make.

That’s more charitable than my cynic’s view, Rick

I struggle to believe that, in some meeting back in the depths of time, that some engineer didn’t pipe up with why not ring fencing the lookahead tables, etc, was a bad idea. And I hate sentences with so many negatives. I’m giving Intel the benefit of the doubt that there are more smart people working there than stupid people.

Considering Intel’s history when it comes to competition just makes it sound all the more unlikely. OK, conspiracy mode off...