Defending against page-cache attacks

Posted Jan 18, 2019 1:32 UTC (Fri) by Nahor (subscriber, #51583)
In reply to: Defending against page-cache attacks by kucharsk
Parent article: Defending against page-cache attacks

> 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 :-(