[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 28 Jun 2011 02:37:12 +0400
From: Solar Designer <solar@...nwall.com>
To: kernel-hardening@...ts.openwall.com
Cc: Vasiliy Kulikov <segoon@...nwall.com>,
KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
linux-kernel@...r.kernel.org, balbir@...ux.vnet.ibm.com,
akpm@...ux-foundation.org, viro@...iv.linux.org.uk,
rientjes@...gle.com, wilsons@...rt.ca, security@...nel.org,
eparis@...hat.com, Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [PATCH 1/2] proc: restrict access to /proc/PID/io
On Mon, Jun 27, 2011 at 12:52:42PM +0400, Vasiliy Kulikov wrote:
> As to random bytes - if it is very predictable (e.g. rand() % 10000) one
> may restore the original value. But it would still do much harm to good
> programs (io stats going up and down!). Adding really random bytes
> seems somewhat too complicated for these needs to me.
Random noise doesn't help very much even if it's totally unpredictable
and even if it's much louder than the signal. It will only increase the
number of samples needed to see the signal through the noise.
More effective ways to deal with side-channel attacks are to make things
appear constant or, better yet, to remove the side-channel altogether
if possible. I'd happily break iotop for non-admins on many of my
systems, so please give me a way to do it.
http://en.wikipedia.org/wiki/Side_channel_attack#Countermeasures
Alexander
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
