Thank you very much George, that is exactly the piece of information I was missing.
Oleg On Wed, Dec 23, 2015 at 10:55 AM, George Neuner <gneun...@comcast.net> wrote: > Hi Oleg, > > On Wed, 23 Dec 2015 07:07:31 -0600, oleg yusim <olegyu...@gmail.com> > wrote: > > >May we run into situation, when attacker dumps memory and analyses it for > >valuable content, instead of reserving it for own process, where it would > >be zeroed? My understanding, it is a possibility. Does kernel have any > >safeguard against it? > > With recent kernels, by default there is no way for a userspace > process (even root) to dump memory. Older kernels by default > permitted a root process unrestricted access to /dev/mem and > /dev/kmem, however in general that isn't needed and has long been > disabled by the mahor distros. [see CONFIG_STRICT_DEVMEM]. IIRC, the > default setting was changed in 2011. > > With sufficient privileges, a debugger-like process can attach and > examine the memory of a running - or just terminated - process, but it > won't have access to discarded (unmapped) memory. > > The MAP_UNINITIALIZED trick, even if it works, is not a predictable > attack vector. There is no way to ask for any *particular* VMM page - > mmap() just gives you a set of pages sufficient to cover the requested > address range ... you don't know what process those pages previously > belonged to. Obviously there is a known algorithm for satisfying the > page requests, but the set of free pages includes both code and data > and depends on the history of system activity. There's no guarantee > to get anything useful. > > I'm not sure any of this really answers your question. > George > > > > -- > Sent via pgsql-general mailing list (pgsql-general@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-general >
