Re: [patch 0/4] MAP_NOZERO v2 - VM_NOZERO/MAP_NOZERO early summer madness

Davide Libenzi
2007-06-29T20:13:50Z

On Fri, 29 Jun 2007, Andy Isaacson wrote:

> On Thu, Jun 28, 2007 at 10:57:00PM -0400, Kyle Moffett wrote:
> > On Jun 28, 2007, at 14:49:24, Davide Libenzi wrote:
> > >So I implemented a rather quick hack that introduces a new mmap()
> > >flag MAP_NOZERO (only valid for anonymous mappings) and the vma
> > >counter-part VM_NOZERO. Also, a new sys_brk2() has been introduced
> > >to accept a new flags parameter. A brief description of the
> > >patches follows in the next emails.
> >
> > Hmm, sounds like this would also need a "MAP_NOREUSE" flag of some
> > kind for security sensitive applications. Basically, I wouldn't want
> > my ssh-agent pages holding private SSH keys to be reused by my web
> > browser which then gets exploited :-D.
>
> PGP at least (and I think GPG still) did overwrite keys before calling
> free(), and attempted to use mlock(). Looks like ssh-agent doesn't use
> mlock -- at least it hasn't in this case:
> % grep Lck /proc/`pidof ssh-agent`/status
> VmLck: 0 kB
> % ulimit -a | grep lock
> file size (blocks) unlimited
> core file size (blocks) 0
> locked-in-memory size (kb) 32
> file locks unlimited
>
> Requiring security-sensitive apps to use a new flag to get safe behavior
> is dangerous. Better to be safe by default and turn on the
> less-safe-but-faster behavior for the cases that benefit from it.

Can you better explain what MAP_NOZERO would alter in such case?

> I still think that using uid in mm_struct is wrong, and some kind of
> abstraction is required. I called this "free pool" in
> <20070628061911.GA16986@hexapodia.org>, but I think that name is
> misleading -- I am not proposing that this should be part of the
> management of free pages, but should be a label which abstracts "safe to
> share freed pages among" groups. Then different SELinux protection
> domains would simply have different labels.

I think I answered this one at least a couple of times, but anyawy. First,
that can be whatever cookie we choose. At the moment UID is used because
it makes easier a fit into _mapcount. Second, SeLinux will be able to
disable the feature on a per-process base, or globally.
Anything else?

- Davide