[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20110627223712.GA8685@openwall.com>
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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists