Defending against page-cache attacks

Posted Jan 17, 2019 21:44 UTC (Thu) by kucharsk (subscriber, #115077)
Parent article: Defending against page-cache attacks

I think the general case problem here is cached data is generally interesting data.

You can extend the paradigm as far out into the computing arena as you like; if a system has both SSD and hard drives, data from SSD will probably be more important or of greater interest than that on the spinning media. If you have a storage solution that sends data off to secondary or tertiary storage, the time it takes to access said data reveals how old the data is.

Likewise on systems with NVRAM, information in NVRAM will generally be more important or interesting than data not kept in non-volatile storage.

This paradigm is of course true for all operating systems, not just Linux.

Timing is always an issue; during the Cold War, Soviet spies were able to wiretap IBM Selectric typewriters in embassies by detecting how long it took the type ball to rotate to each character, giving them a reasonable chance of determining each character being typed.

We obviously can't take the approach of "slow everything down to the time taken to access the slowest device," and there will always be a need to be able to pre-populate clusters, containers or other mechanisms to provide for fast startup times or to provide instant failover. Someone will need access to that information, and as soon as someone does, that's a potential leak.

It's more a matter of reducing exposure than eliminating it, and the question is where does that balance between security and the need for ever faster operation lie?

Defending against page-cache attacks

Posted Jan 18, 2019 1:32 UTC (Fri) by Nahor (subscriber, #51583) [Link] (9 responses)

> I think the general case problem here is cached data is generally interesting data.

Easy solution: just cache everything. Load the whole disk in RAM at boot. No slow access, no timing attack and the system becomes faster. Win-win! :)

Defending against page-cache attacks

Posted Jan 18, 2019 13:36 UTC (Fri) by Sesse (subscriber, #53779) [Link] (6 responses)

By RAM, you mean L1 cache?

Defending against page-cache attacks

Posted Jan 19, 2019 1:45 UTC (Sat) by naptastic (guest, #60139) [Link] (5 responses)

I can fit 2^7 of my first computer in the on-die cache of my five-year-old desktop processor. (Commodore 64 -> i7 4790k)

Defending against page-cache attacks

Posted Jan 20, 2019 18:37 UTC (Sun) by Sesse (subscriber, #53779) [Link]

That's not L1 cache only. You can do cache attacks even if you only have L3.

Defending against page-cache attacks

Posted Jan 20, 2019 20:00 UTC (Sun) by farnz (subscriber, #17727) [Link] (3 responses)

Your i7-4790K has 32 KiB I$ and 32 KiB D$ - so about as much total L1 cache as your C64 had RAM, but not enough to cover the ROM as well.

My first Z80 machine would fit in L1 cache on your CPU, though - the ZX81 had 1 KiB RAM, 8 KiB ROM, and could be expanded commercially to 16 KiB RAM, 8 KiB ROM.

Defending against page-cache attacks

Posted Jan 28, 2019 7:55 UTC (Mon) by paulj (subscriber, #341) [Link] (2 responses)

Complete tangent from the story: That 16 KiB ZX81 RAM pack - it was wobbly, and just as you'd be getting into the end of (what felt like to a 9yo anyway) hours of typing in some programme, it'd wobble, the ZX81 would reset and everything would be gone! Oh that RAM pack, so frustrating! :)

Defending against page-cache attacks

Posted Jan 28, 2019 14:09 UTC (Mon) by gevaerts (subscriber, #21521) [Link]

That's why you built some contraption to keep it all in place! (which is, of course, when something went wrong with saving and you had to re-type it anyway)

Defending against page-cache attacks

Posted Jan 30, 2019 14:42 UTC (Wed) by nix (subscriber, #2304) [Link]

I had a wobbly RAM pack with an extra flaw: the PSU on my ZX81 was underspec so it didn't generate quite enough power to power the RAM and screen at once. The video signal generation was the first thing to go: you got waves of sync problems like a bad VHS video player working their way over the screen. But it didn't take long for eight-year-old me to figure out that the RAM wasn't holding its content either...

(Obviously I couldn't fix it. An eight year old with terrible coordination go messing in a power supply?! HELL NO.)

Defending against page-cache attacks

Posted Jan 18, 2019 19:23 UTC (Fri) by quotemstr (subscriber, #45331) [Link] (1 responses)

Well, yeah. The whole reason we share stuff in the first place is to make efficient use of limited system resources. As resources become cheaper, the case for elaborate (and apparently insecurity-prone) sharing mechanisms diminishes. The future of computing is straight-up partitioning, sharing nothing. It's a much simpler and more robust world.

Defending against page-cache attacks

Posted Jan 24, 2019 5:15 UTC (Thu) by marcH (subscriber, #57642) [Link]

> > > > So the known mechanisms for non-destructively querying the state of the page cache are likely to be shut down, perhaps only if the kernel is configured into a "secure mode".

> The future of computing is straight-up partitioning, sharing nothing. It's a much simpler and more robust world.

To avoid a myriad of new CONFIG_SECURE_SIDE_CHANNEL_FOO options, how about a unique CONFIG_SHARED_SYSTEM setting controlling all these at once?

"Shared" can unfortunately apply to single-user systems too, think Android applications for instance :-(