After further reading, it looks as if /proc/<pid>/mem has a lot of built-in protection already, so that should not be an issue. On Fri, Mar 15, 2013 at 10:27 AM, Luigi Semenzato <semenzato@xxxxxxxxxx> wrote: > On Fri, Mar 15, 2013 at 9:55 AM, Johannes Weiner <hannes@xxxxxxxxxxx> wrote: >> On Fri, Mar 15, 2013 at 08:48:49AM -0700, Luigi Semenzato wrote: >>> On Fri, Mar 15, 2013 at 2:04 AM, Ric Mason <ric.masonn@xxxxxxxxx> wrote: >>> > On 03/12/2013 07:57 AM, Luigi Semenzato wrote: >>> >> >>> >> Greetings linux-mmers, >>> >> >>> >> before we can fully deploy zram, we must ensure it conforms to the >>> >> Chrome OS security requirements. In particular, we do not want to >>> >> allow user space to read/write the swap device---not even root-owned >>> >> processes. >>> > >>> > >>> > Interesting. >>> >>> Thank you. >>> >>> >> >>> >> A similar restriction is available for /dev/mem under >>> >> CONFIG_STRICT_DEVMEM. >>> > >>> > >>> > Sorry, what's /dev/mem used for? and why relevant your topic? >>> >>> I don't know what it's used for Chrome OS, but I don't think it >>> matters. The point is that /dev/mem is compiled in the kernel, and >>> without CONFIG_STRICT_DEVMEM it offers a way for a root-owned process >>> to read/write all of physical memory. The situation is not as dire >>> with a swap device, but currently a root-owned process can open a >>> block device used for swap and peek and poke its data, which means >>> that a root-owned process has now potential access to the data segment >>> of any other process, among other things. >> >> How do you handle /proc/<pid>/mem? > > Right. We do not. But... we might! We could turn it off and see if > it breaks anything important. > > In any case, we don't like expanding the attack surface. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>