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 …
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.
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."
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.
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.
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).
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.
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.
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!
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.
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).
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'.
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.
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
"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.
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.....
"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.
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? !
> 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.
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.
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/FCUKAll2 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.
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.
"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!
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.
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.
> 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!
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?
....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..........
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?
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.
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!
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...
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
