One more reason for Apple to dump Intel processors: Another SGX, kernel data-leak flaw unearthed by experts

Boffins based in Austria, Germany, and the UK have identified yet another data-leaking side-channel flaw affecting Intel processors, and potentially other chips, that exposes cryptographic secrets in memory. In a paper disclosed on Tuesday, computer scientists with Graz University of Technology, University of Birmingham, and …

[Anonymous Coward]

More arguments for AMD, thus?

At this point I'd like to know just how much CPU power I have left for running the services I actually bought the hardware for, versus the bandwidth lost to trying to keeping Intel backdoors shut, and that's just the backdoors we by now know about.

Intel CPUs, the gift that keeps on giving - to the NSA.

[Gene Cash]

Re: More arguments for AMD, thus?

Did you actually READ the article??

"The boffins say they tested their attack on Intel chips but they point to the presence of similar power measurement tools for other microarchitectures, like AMD's RAPL interface which allows instructions executed on AMD Zen CPU cores to be identified.

"This could allow similar attacks on AMD CPUs, e.g., against AMD’s SEV-SNP, where a privileged kernel-space attacker is conceivable," the paper explains, and points to other CPU vendors like Ampere, Arm, Cavium, Hygon, IBM, and Nvidia that offer power measurement interfaces."

[teknopaul]

Re: More arguments for AMD, thus?

Probably not, or AC also did not notice that the mitigations do not have perf impact.

[Aitor 1]

Re: More arguments for AMD, thus?

I suspect they do.. now they have to run on admin privileges.. so because of previous attacks, the change of context is way more expensive, so yes, it does have a cost.. probably relatively small, but it does have a cost.

Also, the more processes you have running as root-admin, the bigger the attacks surface.

[Anonymous Coward]

Re: More arguments for AMD, thus?

This issue is not limited to intel however it must be said that intel seems susceptable to pretty much every side channel and design fail going where other CPU manufacturers have some but not all.

[Richard 12]

Re: More arguments for AMD, thus?

Fortunately, mitigation doesn't have any effect on your CPU performance.

It just makes the power consumption monitoring less precise and timely.

[Pascal Monett]

Seems like isolation is the best solution

Look, I'm a gamer. I like powerful processors (and GPUs). I like high framerates. I like a responsive computer, ie one that does not make me wait for a second every time I click the mouse.

So it seems that I'm going to need an Internet-connected computer for my browsing, and a unsecure but non-connected computer for my playing.

That's going to wreak havoc with multiplayer, but multiplayer is not all that exists.

We'll find a solution.

[Gene Cash]

Re: Seems like isolation is the best solution

> multiplayer is not all that exists

XBox and Playstation are working on that!

[anonymous boring coward]

Re: Seems like isolation is the best solution

My 66MHz 486 never made me wait a second after clicking the mouse.

I ran Linux on it.

My point is that the hardware is plenty powerful even with the simplest PC, today. It's the software that brings frustration. A single web page can go from using 100MB to 1GB in a few days. Leaks? What's that? My 486 was awesomely specified with 32MB RAM, and a stunning 500MB hard drive (0.5GB).

[tcmonkey]

Re: Seems like isolation is the best solution

Yes, but the things you were doing on the machine back in those days were vastly different from the workloads of today. Decoding an MP3 on a machine like that would have consumed almost if not all of the available system resource, to say nothing of full motion video. Sure, some software is crap today, and some of it always will be, but we're asking the machines to do things that would have been utterly impossible not even 10 years ago.

I do wish we'd stop building things with Electron though.

[FeepingCreature]

Re: Seems like isolation is the best solution

> to say nothing of full motion video

Eh, I've only tried this on a Pentium 1 but it worked fine... as long as you pre-transcoded it to a lower resolution and cheaper codec.

[Anonymous Coward]

Re: Seems like isolation is the best solution

Well yes, your 8x8 pixels could be in perfect motion... doesn't make it practical though!

[Mage]

Re: Seems like isolation is the best solution

Full motion video editing at 768 x 568 (PAL square pixel progressive). Final transcode for interlace. On windows for Workgroups 3.11!

MJPEG native format and about 20 minutes of source possible on the hard drive we could afford. Big card with Analogue PAL/NTSC I/O and VGA loop through for 1:1 Hardware Video Overlay.

Adobe Premier as the editing software.

[Anonymous Coward]

Re: Seems like isolation is the best solution

How many colours? :-)

Sorry, fair enough, I was just being a git!

[Anonymous Coward]

Re: Seems like isolation is the best solution

My desktop computer is struggling a bit. It's just a little slow on some webpages, especially if I have a lot of tabs open. I'm running Ubuntu 18.04 on it. Relevance? It was built to run WinXP, and has only had memory and hard drive upgrades since then, and is maxed out at 8 GB memory. STILL runs better than XP ever did, and could not possibly run "up to date" Windows.

"Some" software is crap. As in, the most commonly used stuff!

[DCFusor]

Re: Seems like isolation is the best solution

The raspi 4b I'm using as a daily driver for my off-grid homestead - winter cuts down the hours I can use the big stuff (solar), is good for revealing who writes lousy scripts and bloated websites. Other than that, browsing, editing and testing code, running services like a local NGINX, MySQL and some perl CGI's while polling some LAN of things devices on the homestead and making plots with gnuplot - with data stuffed into MySQL and served by NGINX to a local chromium) no problems. The pi is mostly loafing.

The main issues are with pages made with some bloated framework that allow unskilled to add content without considering sizes and formats, and frankly, gmail's webpage seems to go slower and slower until it's taking 20 seconds to respond to a keystroke in chromium. Some opaque script I suppose, written by developers who only test on their big dev machines- a common issue.

Everything else is quick enough not to matter to me, even driving two 1080p displays with YouTube on one of them.

Yes, it's overclocked to 2 ghz and runs from a gumstick drive with a USB3 adapter. Fairly swank.

[Version 1.0]

This is news?

One more reason to dump processors: Today's kernel data-leak flaw unearthed by experts... fixed it for you. We design processors and all systems these days to make them fast and easy to use. Security? Yea, we've heard of it. Is there anything out there that can't be hacked today? Do you really believe that you can build something that has Internet access and is perfectly safe?

Hacking is normal (and fun too).

[DoctorNine]

Re: This is news?

The idea of monitoring some parameter of the chip to infer what it is doing, rather than trying to steal the data from the processing stream directly, has been around for decades at least. I messed around with it a little bit in the 1990's for fun. The thing about information processing, is that there are almost an infinite number of ways that the mechanism of the processing device reveals its instructions indirectly. Power monitoring, RF signatures, heat maps/time. Given some form of access to the chip, physically or remotely, there really isn't such a thing as perfect security. So exploits like this are inevitable artifacts of the act of information processing itself. I forget sometimes that most people don't really understand what goes on in those magical boxes called 'computers'.

[swm]

Re: This is news?

Back in 1966 on the Dartmouth time sharing system there was a top-level file that was all of physical memory. It was protected. Someone thought it would be harmless to grant read access to this (pseudo) file. Someone else then discovered a simple password cracker by trying to open up a file and scanning memory for the file name and looking nearby for the password. Worked like a charm.

When I found out about it I asked, "What were you thinking?"

Don't let random people mess with stuff they don't understand.

[Mike Pellatt]

Re: This is news?

Don't let random people mess with stuff they don't understand.

Chip designers in particular :-) , since this problem has been made much worse by speculative execution and all the other shenanigans to improve performance.

I often wonder where we'd be if VLIW had delivered on its promise of beating both CISC and RISC

[Anonymous Coward]

Re: This is news?

"I often wonder where we'd be if VLIW had delivered on its promise of beating both CISC and RISC"

If you look at this flaw and think it is caused by the instruction architecture, you've missed the point.

This is about using supplemental hardware to either monitor or hide sensitive information from the main CPU to "improve" performance or security. Or not in this case. The CPU's that don't have this supplemental hardware rely on the OS to hide the sensitive information instead.

[Mike Pellatt]

Re: This is news?

Clearly, the specific vulnerability in the article wasn't caused, directly, by the instruction architecture.

But I was following up to a more generic issue over what you do with your system.

And I'd suggest that the vulns of this type (including Spectre,etc.) we're seeing today are, at least in part, thanks to the prevalence of a CISC architecture and the huge system complexity we now find ourselves with as we play whack-a-mole with each performance bottleneck that pops up.

Or whack-an-elephant back in the days of trying to sort out SMP.....

[Anonymous Coward]

Re: This is news?

"And I'd suggest that the vulns of this type (including Spectre,etc.) we're seeing today are, at least in part, thanks to the prevalence of a CISC architecture"

And I would respectively disagree.

Why are we putting these bolt-on "micro-CPU's" onto larger CPU's? For performance and hardware-level "security" so that we don't have to trust higher levels in the stack (i.e. firmware/OS/application etc) to implement them.

This has led to better thermal/power management on the physical side while alse providing things such as DRM/TPM on the security side. We can lose these features but the side effect is that we lose the benefits as well. i.e. earlier CPU designs

The real question is how significant is this flaw? It likely breaks DRM (again) but has little impact on TPM given that most TPM users will be Windows/OSX and they don't directly expose an interface to allow access to this hardware in the way Linux does.

So while it is a flaw and a better solution is needed, it doesn't either remove the need for this approach or completely invalidate this as the best available security model.

[Anonymous Coward]

Re: This is news?

Of course, all these side-channel attacks are all the more problematic when the environmental leaks are monitored and made available to the OS (timing metrics, temperature readings, and power usage as mentioned in this article)

What next? An onboard device and corresponding API to monitor spurious RF? !

[juice]

Re: This is news?

> The idea of monitoring some parameter of the chip to infer what it is doing, rather than trying to steal the data from the processing stream directly, has been around for decades at least. I messed around with it a little bit in the 1990's for fun

This.

To use the always-popular car analogy, this is a bit like installing a microphone inside the engine bay.

By listening to the engine, you'd be able to build up a picture of the engine's revs, as well as things like gear changes, etc.

And from that, you'd be able to build up a map of where the car has travelled to.

E.g. high revs for two minutes, followed by idling for 30 seconds: drove 0.75 miles down the road, stopped at traffic lights.

It wouldn't be particularly precise, but over time - as per exploits like this - you'd be able to create a pretty good model.

Fundamentally, any activity which produces detectable side-effects can be passively monitored, and data extracted from that monitoring. There's even been exploits which listen to PSU fan speeds, as that's a sign the CPU is pulling more power...

The trick is to minimise these side effects and/or restrict access to them.

[Snake]

Intel power patch

Just realized that Intel claims that their patch mitigates the flaw by giving only predictive modeling. But how will that affect systems like XTU and ThrottleStop, which use those hard numbers to control the CPU? Now, they'll only get a predictive average, not true power consumption.

[Anonymous Coward]

Re: Intel power patch

Aren't we just talking a matter of resolution, and over small time periods? Data far from accurate enough for exploiting this would be more than fine for CPU throttling.

[Claptrap314]

Re: Intel power patch

You throttle CPUs in response to heat build-up, NOT power consumption. Different parts are used to monitor heat and power consumption.

[Anonymous Coward]

Is that right?

This is a vulnerability that affects Linux but MacOS and Windows are safe? Gosh!

[amanfromMars 1]

Re: Is that right?

Is that right? This is a vulnerability that affects Linux but MacOS and Windows are safe? Gosh! .... Anonymous Coward

Strewth! What does one have to do to sublimely entertain and better educate the dreadfully slow to learn from past known and well enough documented mistakes/vulnerabilities for exhaustive serial exploitation.

What parts of the clear message that nothing/zilch/nada/FCUKAll² is safe and secure, conveyed to you personally by both the originating tale [thanks, Thomas Claburn in San Francisco] and subsequent readers' comments [thanks, El Regers], do not compute for/with you, AC? Has the capacity and ability of your brain to accept and further process and progress novel information into useful greater intelligence been exceeded.

There's nothing to be done able to fix that limitation. Enjoy what you know and the rest will just pass you by and leave you most probably alone with no future need of your help or engagement. Some find it comforting in such a circumstance to realise they are not alone and their worlds abound with others similarly affected/effected/infected/disenfranchised.

[Anonymous Coward]

Re: Is that right?

Quote -> "An update to the Linux powercap driver has been devised to limit unprivileged access to the Intel RAPL MSRs (machine specific registers). On macOS and Windows, access to the Intel RAPL requires the installation of the Intel Power Gadget, so neither of those two operating systems have to mount a native defense against Platypus."

I have just spent what feels like 20 years being told that 'Linux is SO secure and SO safe....only retards use Windows' by commetards like you. I just thought I would have a sarcastic little dig. Sorry you have no sense of humour.

Your rant was kind of the point of my post

P.S. I use all three of the above mentioned operating systems and have used several others.

[Anonymous Coward]

Re: Is that right?

"I have just spent what feels like 20 years being told that 'Linux is SO secure and SO safe....only retards use Windows' by commetards like you. I just thought I would have a sarcastic little dig. Sorry you have no sense of humour."

1) Your "dig" wasn't validly based on the actual situation.

2) Your "dig" wasn't funny.

"P.S. I use all three of the above mentioned operating systems and have used several others."

Or "I'm not racist! Some of my friends are black!"

P.S. If you dislike this post, sorry you have no sense of humor!

[Anonymous Coward]

Re: Is that right?

The vulnerability is exploitable because Linux actually has an API to read the data the CPU generates.

Windows doesn't.

Your argument is about as sane as saying that my ZX Spectrum isn't vulnerable to internet exploits, or that an OS that doesn't have USB support isn't vulnerable to USB dongle hacks.

[Mage]

Re: Windows doesn't.

Windows doesn't by default. But presumably it could be added. Maybe even as a trojan in some other innocuous package, SW or HW. Or by a gift of a doctored USB mouse or Badge. HID is wonderfully insecure. I bought a €7 LED badge and discovered it's custom USB HID rather than serial or mass storage.

[Anonymous Coward]

Re: Is that right?

So the vulnerability IS exploitable on Linux, but IS NOT exploitable on Windows?

Right, good to get that clear.

Don't see why that is a reason to call someone a racist though. That is not very nice.

[juice]

Re: Is that right?

> So the vulnerability IS exploitable on Linux, but IS NOT exploitable on Windows?

Incorrect.

It's natively exploitable on Linux. It's not natively exploitable on Windows.

However, given that the exploit involves "read data from this API", I'm guessing that if you can get your malware onto a windows machine, you can then also include the software needed to read the data from said API.

Unless of course, Windows has restricted access to said API. Which I wouldn't lay a huge amount of money on, unless they've done so in response to this security advisory!

[Matthew 25]

Re: Is that right?

Sorry I don't get your point..?

There are 2 cars lets call them L and W.

L is unlocked and has the keys in the ignition.

W is locked and the keys are far away.

They can both be stolen but which is vulnerable?

Yes, you could pick the locks, or smash a window, but I know which theft my insurance would pay out on.

So it is OK for Linux to be wide open because Windows could be broken in to?

[Sparkus]

....and every one of those firmware 'updates' slows down the processor measurably.....

One reason why my two machines are still on 7th gen i7 cpus. The performance lost in the 8-10th generations by these fixes wasn't worth the cost of 'upgrading' on Intels or Microsoft schedules.

I am optimistic for the 11th gen cpus and Xe IGPs though. So far, so good..........

[Dave Pickles]

"....and every one of those firmware 'updates' slows down the processor measurably....."

My well-travelled notebook runs Linux 4.14.4, the last version before Spectre, along with the microcode and firmware from that time.

[hollymcr]

A spokesperson for AMD didn't immediately respond to a request for comment.

You say:

"The researchers say they've disclosed the issue to both Arm and AMD. A spokesperson for AMD didn't immediately respond to a request for comment."

Does this mean Arm did respond (immediately)? What did they say?

[John Smith 19]

Mo' interfaces. Mo' problems

<sigh>

Again.

[stiine]

Re: Mo' interfaces. Mo' problems

Again, please, with more feeling...

[fidodogbreath]

Re: Mo' interfaces. Mo' problems

Again, please, with more mo' feeling...

FTFY

[Arthur Daily]

Power factor is not new

Sigh. Cambridge University identified this at least 15 years ago. And reconnecting laser cut test circuitry. Lithium Nicobate watching. A solution is a zener diode on the power line and a few gates to add power randomness. Also note the management chip is also vulnerable. Or Apple T2..I think the first example may be IBM's VM in late 1960's where hard loops on one VM could morse code messages to the other VM. Worse the Intel 'fixes' advertise where flush routines get run. I was wrong when I thought Intel would dump defective speculation leaks, and make fixing THE first priority. However when pipelining is >8 deep.

Lots to be said for the MIP's processor. I don't trust ARM, as some versions used Intels pre-ex logic blog to have the same errors as Intel.

[Caver_Dave]

Re: Power factor is not new

I was personally in meetings in late 2001 where what became spectre was discussed as a possible issue!

[dajames]

Thanks, Intel

The media companies may want those DRM keys to remain secret, but I'm pretty sure nobody else's interest is served by that.

We should all thank Intel for giving us a relatively easy (and deniable) means to extract those keys, thus defending our right to play our licensed media wherever we want!

[Zippy´s Sausage Factory]

Re: Thanks, Intel

The idea of Intel having to rapidly patch flaws because the RIAA and MPAA tell them to feels like we've gone down the rabbit hole far enough that not only are we not in Kansas any more, but that definitely wasn't chicken...

[Anonymous Coward]

So exploitation (unsurprisingly) relies on getting some malware onto the machine? But Apple and Linux users never tire of telling folk that you can't get malware on their machines...

[Anonymous Coward]

https://en.wikipedia.org/wiki/Formal_fallacy

[Anonymous Coward]

Why not simply

change it to a 5-second average, rather than instantaneous readings (insecure) or predictive readings (inaccurate)?

[Claptrap314]

Re: Why not simply

A 5-second average is called a "temperature measurement". Good for things like knowing when to throttle the part. No so good when figuring out which critical inner loop is about to go critical.

I don't know if self-detuning code is a thing. That's about the only application use case I can think of that makes sense for this API.

HW people really don't get sw. And sw people don't get hw. (As a rule in both cases.) When I was doing microprocessor validation, the hw guys were constantly coming up with brilliant but useless ideas about providing more dingle-dangles for sw guys to play with. I was not at the level to know if there was a security team reviewing ideas before they went into the design. Somehow, I doubt that there was...

[Anonymous Coward]

Userspace

Just don't have the interface accessible in userspace?

[Anon]

Apple?

"The paper explains, and points to other CPU vendors like ... Arm ... ." So, Apple's new system may also be vulnerable.

Did The Register get any reply from Apple on the matter yet?

[fidodogbreath]

Magic trick

Moose: "Hey, Rocky! Watch me pull sensitive protected data out of my Intel CPU!"

Squirrel: "Again? That trick always works."

Moose: "Don't worry, it's sure to work again this time!"

[Anonymous Coward]

move to ARM

I fail to see how one of the various HW flaws pushes towards ARM.

Yes, Intel has had plenty because they never cared about security, only GHz.

But to make this a valid reason for Apple to go ARM is a bit too much.

Plenty of reasons against it actually.