Dave Hansen <d...@sr71.net> writes: > On 03/12/2015 03:35 PM, Andrew Morton wrote: >> On Mon, 09 Mar 2015 13:43:21 -0700 Dave Hansen <d...@sr71.net> wrote: >>> From: Dave Hansen <dave.han...@linux.intel.com> >>> >>> Physical addresses are sensitive information. There are >>> existing, known exploits that are made easier if physical >>> information is available. Here is one example: >>> >>> http://www.cs.columbia.edu/~vpk/papers/ret2dir.sec14.pdf >> Do we really need to disable pagemap entirely? What happens if we just >> obscure the addresses (ie: zero them)? > > I think we have 3 basic options: > > 1. Disable it entirely (-EPERM or whatever). Apps using it break > quickly and fairly obviously (diagnosable with an strace) > 2. Zero it, or return some nonsensical thing for the physical address > portion, but maintain exporting the PTE flags. Apps only caring > about PTE flags work, but anything trying to do lookups in > /proc/kpageflags break. If we zero it, apps pay get confused > thinking they have the _actual_ pfn=0. > 3. Scramble it in some way obscuring the physical address. Unscramble > it upon access to /proc/kpageflags. > > I think you're suggesting (2). Doesn't that risk silently breaking > apps?
I think 3 where the scramble is something like AES crypto is likely to scramble this well and still protect us from plain text attacks. >>> pagemap is also the kind of feature that could be used to escalate >>> privileged from root in to the kernel. It probably needs to be >>> protected in the same way that /dev/mem or module loading is in >>> cases where the kernel needs to be protected from root, thus the >>> choice to use CAP_SYS_RAWIO. >> >> Confused. If you have root, you can do mount -o notparanoid. > > Good point. I guess it doesn't protect us much here unless we also > restrict the ability to remount. And the ability to unmount... A write-once sysctl or a boot time only parameter is much more likely to be useful in the scenario where you are concerned about root. Eric -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
