> Processes could create a page of memory with known contents then, after
> waiting for the checker process (or kernel thread) to run, see if memory
> usage has increased.
I don't believe that's a real security issue at all. Absolutely anything could run in the meantime, with memory being both freed and allocated by completely unrelated causes. At best, such processes would be able to say it was possible that the page was shared, which really says nothing.
Posted Dec 4, 2008 3:12 UTC (Thu) by mjg59 (subscriber, #23239)
[Link]
Anything could run, but it's possible that nothing will. And that means that a sufficient number of repetitions may show a significant deviation from what you'd expect from chance alone, which is an information leak.
What security issue?
Posted Dec 5, 2008 0:11 UTC (Fri) by nix (subscriber, #2304)
[Link]
TBH preventing information leaks on any single system is a hopeless task:
there are far too many potential avenues, and when you get right down to
it they *are* one single system, so one process consuming a shareable
resource will always be observable by another process attempting to get
access to the same resource. (Crude example: time. Busywait, watching the
time: if it skips, you know someone else is using the same core.)
If you want to avoid information leaks, run the high-sensitivity no-leak
stuff on a different physical machine. Nothing else is safe enough for the
paranoid, and only the paranoid will really care about this anyway.
What security issue?
Posted Dec 11, 2008 14:49 UTC (Thu) by anton (guest, #25547)
[Link]
I think a more reliable leak is to then write in the page, and see if
the write takes a long time (due to copy-on-write). There were other
potential information leaks discussed, but IMO they were all pretty
far-fetched and can be defended against (e.g., don't make it
predictable when pages will be merged; on the application side, when
inputting passwords, initialize the buffer with random data).