On Thu, Oct 31, 2019 at 12:17 PM Mike Rapoport <rppt@xxxxxxxxxx> wrote: > > On Wed, Oct 30, 2019 at 09:19:33AM +0100, David Hildenbrand wrote: > > On 30.10.19 09:15, Mike Rapoport wrote: > > >On Tue, Oct 29, 2019 at 12:02:34PM +0100, David Hildenbrand wrote: > > >>On 27.10.19 11:17, Mike Rapoport wrote: > > >>>From: Mike Rapoport <rppt@xxxxxxxxxxxxx> > > >>> > > >>>The mappings created with MAP_EXCLUSIVE are visible only in the context of > > >>>the owning process and can be used by applications to store secret > > >>>information that will not be visible not only to other processes but to the > > >>>kernel as well. > > >>> > > >>>The pages in these mappings are removed from the kernel direct map and > > >>>marked with PG_user_exclusive flag. When the exclusive area is unmapped, > > >>>the pages are mapped back into the direct map. > > >>> > > >> > > >>Just a thought, the kernel is still able to indirectly read the contents of > > >>these pages by doing a kdump from kexec environment, right? > > > > > >Right. > > > > > >>Also, I wonder > > >>what would happen if you map such pages via /dev/mem into another user space > > >>application and e.g., use them along with kvm [1]. > > > > > >Do you mean that one application creates MAP_EXCLUSIVE and another > > >applications accesses the same physical pages via /dev/mem? > > > > Exactly. > > > > > > > >With /dev/mem all physical memory is visible... > > > > Okay, so the statement "information that will not be visible not only to > > other processes but to the kernel as well" is not correct. There are easy > > ways to access that information if you really want to (might require root > > permissions, though). > > Right, but /dev/mem is an easy way to extract any information in any > environment if one has root permissions... > I don't understand this concern with /dev/mem. Just add these pages to the growing list of the things /dev/mem is not allowed to touch.
