CPU International Crisis - Are We All Doomed?

for all subjects/topics not covered by the other forum categories
User avatar
BeebMaster
Posts: 2530
Joined: Sun Aug 02, 2009 4:59 pm
Location: Lost in the BeebVault!
Contact:

CPU International Crisis - Are We All Doomed?

Postby BeebMaster » Thu Jan 04, 2018 11:22 pm

What's all this about then?

http://www.bbc.co.uk/news/technology-42562303

Are we all doomed?

I expect my Beebs are safe, but what about the RISC PC and Raspberry Pi ?

Has everyone on here signed the non-disclosure agreement to hush it up, or can we talk about it??
Image

dp11
Posts: 754
Joined: Sun Aug 12, 2012 8:47 pm
Contact:

Re: CPU International Crisis - Are We All Doomed?

Postby dp11 » Thu Jan 04, 2018 11:38 pm

The issue is about one process reading data that it shouldn't have access to.

If you allow random people to log in to your pi then they could read all of the memory which might have say passwords in it.

If you run a Web browser on your pi and go to a website with special java script on it then it can read all your memory too.

crj
Posts: 832
Joined: Thu May 02, 2013 4:58 pm
Contact:

Re: CPU International Crisis - Are We All Doomed?

Postby crj » Fri Jan 05, 2018 1:58 am

Risc PCs are old enough to be definitely safe. Even the StrongARM relied on fast logic and a deep pipeline rather than speculative execution and branch prediction for its speed.

Raspberry Pi's are new enough to be affected, but ARM claims the specific CPUs they use are not.

User avatar
flibble
Posts: 624
Joined: Tue Sep 22, 2009 10:29 am
Contact:

Re: CPU International Crisis - Are We All Doomed?

Postby flibble » Fri Jan 05, 2018 2:49 am

crj wrote:Risc PCs are old enough to be definitely safe. Even the StrongARM relied on fast logic and a deep pipeline rather than speculative execution and branch prediction for its speed.


Only if you're running Linux on your Risc PC, RISC OS is so fundamentally insecure that you don't need any of these clever side channel attacks to perform these types of insecure reads from other processes. There's no security separation between user space and supervisor space under RISC OS.

Raspberry Pi's are new enough to be affected, but ARM claims the specific CPUs they use are not.


This is likely due to the Pi's being based on the 'simpler'/'cheaper' cores that don't implement speculative execution in the same way. (Once again this is only true for Linux, RISC OS is broken by design).

User avatar
sweh
Posts: 1914
Joined: Sat Mar 10, 2012 12:05 pm
Location: New York, New York
Contact:

Re: CPU International Crisis - Are We All Doomed?

Postby sweh » Fri Jan 05, 2018 3:06 am

Rgds
Stephen

crj
Posts: 832
Joined: Thu May 02, 2013 4:58 pm
Contact:

Re: CPU International Crisis - Are We All Doomed?

Postby crj » Fri Jan 05, 2018 3:11 am

flibble wrote:
crj wrote:Risc PCs are old enough to be definitely safe.

Only if you're running Linux on your Risc PC

OK. Old enough to be definitely safe from these two specific exploits. Happy? :-p

User avatar
flaxcottage
Posts: 3026
Joined: Thu Dec 13, 2012 8:46 pm
Location: Derbyshire
Contact:

Re: CPU International Crisis - Are We All Doomed?

Postby flaxcottage » Fri Jan 05, 2018 8:46 am

Oh no!

Now there will be more calls from the Indian boiler house people claiming my Pi is being attacked by hackers. :(
- John

Why do I keep collecting Acorn gear? I'm going to need a considerably bigger man-cave. :?

User avatar
1024MAK
Posts: 7291
Joined: Mon Apr 18, 2011 4:46 pm
Location: Looking forward to summer in Somerset, UK...
Contact:

Re: CPU International Crisis - Are We All Doomed?

Postby 1024MAK » Fri Jan 05, 2018 6:46 pm

It's simple.

Just dedicate web browsing to a computer that has absolutely no private information on it and keep your private information on a separate system that has no internet connection :wink:

Oh, and all 8 bit, and a lot of older 16 bit/32 bit systems have no, little or ineffective protection to prevent one process from reading the data of another process...

Mark
For a "Complete BBC Games Archive" visit www.bbcmicro.co.uk NOW!
BeebWiki‬ - for answers to many questions...

User avatar
sweh
Posts: 1914
Joined: Sat Mar 10, 2012 12:05 pm
Location: New York, New York
Contact:

Re: CPU International Crisis - Are We All Doomed?

Postby sweh » Fri Jan 05, 2018 7:53 pm

FWIW, it seems the cores used in the Pi aren't vulnerable

https://www.raspberrypi.org/blog/why-ra ... -meltdown/

"The lack of speculation in the ARM1176, Cortex-A7, and Cortex-A53 cores used in Raspberry Pi render us immune to attacks of the sort."
Rgds
Stephen

Coeus
Posts: 746
Joined: Mon Jul 25, 2016 11:05 am
Contact:

Re: CPU International Crisis - Are We All Doomed?

Postby Coeus » Fri Jan 05, 2018 8:43 pm

I have just been reading the paper on the Meltdown attack and it seems these latest attacks are only the latest is a series of attacks that make use of the fact that the state of the cache can be measured by a process running on the CPU. It seems to me, therefore, that it would be much better to set about making it impossible for a process running on the CPU to determine the state of the cache than to try to deal with each exploit as it comes.

Anyone know what would be involved and why it is not being done? At a guess I would think it would involve:
  • Making any instruction that sets the cache to a known state a privileged instruction that cannot be executed by normal use processes.
  • Not including a timer that has sufficient resolution to be useful for this kind of measurement
or some combination of the two.

User avatar
richardtoohey
Posts: 3563
Joined: Thu Dec 29, 2011 5:13 am
Location: Tauranga, New Zealand
Contact:

Re: CPU International Crisis - Are We All Doomed?

Postby richardtoohey » Fri Jan 05, 2018 10:37 pm

I think if you have home machines (well, ones built after 1995!), you just upgrade them and carry on with life.

If you are responsible for servers, you'll still be waiting (like me) to find out how bad the performance impacts are going to be.

But as Bruce says, this is probably just the beginning of research on this sort of thing:

https://www.schneier.com/blog/archives/ ... mel_1.html

And we've probably all got data on "the cloud" without knowing about it ... loyalty cards, utility companies, governments, etc., etc. store their data about us somewhere ...

SteveBagley
Posts: 150
Joined: Sun Mar 15, 2015 8:44 pm
Contact:

Re: CPU International Crisis - Are We All Doomed?

Postby SteveBagley » Sat Jan 06, 2018 12:07 am

Coeus wrote:[*]Not including a timer that has sufficient resolution to be useful for this kind of measurement[/list]
or some combination of the two.


That's not possible -- I think people demoed Spectre attacks using javasciprt in another thread that just decremented a counter to time the fetches from the cache.

Steve

crj
Posts: 832
Joined: Thu May 02, 2013 4:58 pm
Contact:

Re: CPU International Crisis - Are We All Doomed?

Postby crj » Sat Jan 06, 2018 3:01 am

Coeus wrote:Anyone know what would be involved and why it is not being done?

To my mind, the key problem is that the innards of most CPUs are insufficiently modular, which means it's hard for the engineers to make closely-reasoned arguments about security. Plus middle management doesn't take the question seriously enough.

But also, this kind of thing is hard. Side-channel attacks have been a nightmare for cryptographers for decades; now that people are applying similar techniques to OS privilege boundaries there may be more unfortunate results to follow.

These recent problems are a form of side-channel attack: unprivileged code provoking the system into performing speculative execution on the basis of privileged data in a way that exposed that data to a timing attack. The direct fix would be for CPUs to stall speculative execution in the presence of a privilege boundary, but I fear there's ample scope for some similar attack in a few years' time once everyone has next-generation CPUs which fix this specific issue. They have to fix all problems of this kind, not just the first one anybody noticed. )-8

Coeus
Posts: 746
Joined: Mon Jul 25, 2016 11:05 am
Contact:

Re: CPU International Crisis - Are We All Doomed?

Postby Coeus » Sat Jan 06, 2018 1:55 pm

crj wrote:But also, this kind of thing is hard. Side-channel attacks have been a nightmare for cryptographers for decades; now that people are applying similar techniques to OS privilege boundaries there may be more unfortunate results to follow.


It was the references to a list of previous side-channel attacks, mostly against cryptography, that also used cache timing as the side channel that gave rise to the idea of trying to close off access to that side channel though it seems this is easier said than done.

crj wrote:...The direct fix would be for CPUs to stall speculative execution in the presence of a privilege boundary...


The issue here, as I understand it, is that it is not the instruction itself that is privileged but the memory it accesses so that means even when doing speculative execution the privilege bits in the page tables would need to be checked. That means speculative execution can now hit an exception so then speculative execution has to stop until it becomes apparent whether that exception should be handled or suppressed.

crj wrote:...but I fear there's ample scope for some similar attack in a few years' time once everyone has next-generation CPUs which fix this specific issue. They have to fix all problems of this kind, not just the first one anybody noticed. )-8


Indeed, hence the idea of "can we solve a bunch of these together". But now the cat is out of the bag the CPU designers should be looking at the whole class of problems one way of another.

User avatar
sweh
Posts: 1914
Joined: Sat Mar 10, 2012 12:05 pm
Location: New York, New York
Contact:

Re: CPU International Crisis - Are We All Doomed?

Postby sweh » Sat Jan 06, 2018 2:23 pm

Coeus wrote:I have just been reading the paper on the Meltdown attack and it seems these latest attacks are only the latest is a series of attacks that make use of the fact that the state of the cache can be measured by a process running on the CPU. It seems to me, therefore, that it would be much better to set about making it impossible for a process running on the CPU to determine the state of the cache than to try to deal with each exploit as it comes.

"I want to read memory location X; if the read returns in 1ns then I know it came from cache, if it takes longer than 10ns then I know it wasn't in cache".

We're not measuring the cache directly, we're _inferring_ the state of the cache... because it's a cache and makes reads faster! How do you stop that sort of inference happening without negating the rationale for having a cache in the first place?
Rgds
Stephen

User avatar
1024MAK
Posts: 7291
Joined: Mon Apr 18, 2011 4:46 pm
Location: Looking forward to summer in Somerset, UK...
Contact:

Re: CPU International Crisis - Are We All Doomed?

Postby 1024MAK » Sat Jan 06, 2018 2:38 pm

The only long term solution that I can see, is for a different architecture. Maybe splitting different code between different CPU cores that each have their own cache and therefore run completely independently from one another. The system to copy main memory to the various cache memory would however have to be carefully designed. Maybe even only allowing a fixed repetitive block copy at the cost of a large copy eating up memory bandwidth (hence no useful timing information would be available). This system would then likely make it much harder for code running in less secure CPU cores to gain access to any part of the more secure code / core / cache.

Mark
For a "Complete BBC Games Archive" visit www.bbcmicro.co.uk NOW!
BeebWiki‬ - for answers to many questions...

crj
Posts: 832
Joined: Thu May 02, 2013 4:58 pm
Contact:

Re: CPU International Crisis - Are We All Doomed?

Postby crj » Sat Jan 06, 2018 7:49 pm

1024MAK wrote:The only long term solution that I can see, is for a different architecture. Maybe splitting different code between different CPU cores that each have their own cache and therefore run completely independently from one another.

That's simultaneously too costly and ineffective. )-8

You can perform timing attacks even if there's a WAN in the way. It's harder, sure, but there have been proofs of concept.

It's also not as though we've only just started thinking about how to fix such problems in the past week. I mean, when I was an undergraduate I remember hearing about an IBM MVS/360 bug from the early eighties: get a page of memory mapped immediately below an unmapped page. Put "A" in the final byte of the memory. Call the OS routine which asks "Please check that 'Afault' is the password for user 'KIM' ". It would either return 'no' or 'page fault' depending on whether the first letter of KIM's password was 'A'. It's easy to see how you could quickly determine KIM's entire password.

Avoiding leaking information from privileged code to unprivileged via side channels is hard.

Coeus
Posts: 746
Joined: Mon Jul 25, 2016 11:05 am
Contact:

Re: CPU International Crisis - Are We All Doomed?

Postby Coeus » Wed Feb 07, 2018 10:09 pm

Interestingly, I was querying /proc/cpuinfo on one of my Linux machines (to see how the CPU compared to those in the logical analyser threads) and noticed a new line:

bugs : cpu_meltdown spectre_v1 spectre_v2

I know Linus had some angry words at the time - maybe this is the result.

Kazzie
Posts: 76
Joined: Sun Oct 15, 2017 7:10 pm
Location: North Wales
Contact:

Re: CPU International Crisis - Are We All Doomed?

Postby Kazzie » Fri Feb 09, 2018 10:07 am

Coeus wrote:Interestingly, I was querying /proc/cpuinfo on one of my Linux machines (to see how the CPU compared to those in the logical analyser threads) and noticed a new line:

bugs : cpu_meltdown spectre_v1 spectre_v2

I know Linus had some angry words at the time - maybe this is the result.


Newer Linux kernels report the vulnerability of the CPU to meltdown/spectre attacks. Not only can you see the status via /proc/cpuinfo, but so can the software you run; it can then change how it lays out its stuff in memory accordingly.
Pudsey - BBC Model B 32k issue 7, Sidewise ROM board with 16K RAM
Archimedes 420/1 upgraded to 4MB RAM (mid- restoration)