Subject: Re: new mremap(2): relax alignment restrictions?
To: Eric Haszlakiewicz <erh@nimenees.com>
From: Antti Kantee <pooka@cs.hut.fi>
List: tech-kern
Date: 07/30/2007 23:43:08
On Mon Jul 30 2007 at 11:46:19 -0500, Eric Haszlakiewicz wrote:
> > > 5) Zero the page at mmap time.  Fixes all cases except two concurrently
> > > running processes reading and writing to the area beyond the end of the
> > > file.  Some performance drop, but less than the other options.
> > 
> > Some?  If you zero the pages of e.g. /bin/ls every time you run it, I'd
> > assume a little more than "some" performance drop.  And if you don't do
> > it in the exec path, I would be very careful to make sure it can't be
> > exploited to circumvent the zeroing protection.
> 
> jodi: ktrace ls > /dev/null
> jodi: kdump | grep "CALL.*mmap" | wc -l
>       11
> 
> On a recursive ls through /usr, I saw that 11 go up to 19.  Assuming i386
> and 4096 byte pages, that's ~77k (4095 * 19).  During the same period, 
> ls writes out ~1800k, so 77k is ~4.2%.

No I meant the mmap (or actually direct uvm_map) of the binary itself.

> That could have a significant impact, but to really know how much, I think 
> we'd need to try it and see.
> 
> However, for things like executables and libraries, that are mapped read-only,
> we'd only have to zero the page if some other process had opened the file
> in write mode since the last time we zero'd it, which would probably drop
> the overhead for those to ~0.

That's likely true.

However, couldn't a process circumvent the zeroing protection by simply
mapping beyond the end of the file and keeping the mapping while waiting
for someone to write there?

If it's a shared page, you can't zero it without risking overwriting
some application's data.

And if mapping beyond the end is not legal, you'd also need to zero every
time you truncate a file.  That's probably not a very common operation,
though.

Of course the really clever attacker would increase the file size after
the attackee has mapped it (assuming priviledges).

more gray areas to chew on ;)

-- 
Antti Kantee <pooka@iki.fi>                     Of course he runs NetBSD
http://www.iki.fi/pooka/                          http://www.NetBSD.org/
    "la qualité la plus indispensable du cuisinier est l'exactitude"