--CUfgB8w4ZwR/yMy5
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, Jul 25, 2007 at 04:51:46PM -0400, der Mouse wrote:
> >>> I suppose there's a bit of a performance hit with zeroing out the
> >>> page every time, but it seems like a necessary thing to do.
> >> There are security implications if we're not doing so.
>=20
> There may be.  If the only data available dates from a previous mmap of
> the same file, I'm not sure there's more here than a covert channel for
> passing data that is very hard to find - though that much is certainly
> noteworthy; whether it Needs Fixing is debatable, though I'm in favour
> of it.  (I'd actually *prefer* getting SEGV/BUS/etc for accesses to
> space after EOF, but that would be quite run-time expensive to do, and
> likely somewhat difficult besides.)

We should check, but I doubt there is a security issue here. All you're=20
going to find is anything extra you scribbled while the page was in cache.=
=20
And you have to have write access to do that, so you could have written=20
the file anyway.

Since the data aren't making it back out to disk, all you have is a space=
=20
of memory you can scribble in. And all you can ever find there is=20
something you scribbled there previously. And if the VM page representing=
=20
this gets reused between uses (i.e. when its inactive), then you lose what=
=20
you wrote.

> > echo "12345123451234" > test
> > gcc aa.c
> > ./a.out
>=20
> I don't recall seeing anything upthread about which versions suffered
> from this bug (yes, I consider this a bug).  So I moved the declaration
> of p to make aa.c compile on older releases and started testing.
> ("1.4T+" here is my mutant patched 1.4T.)  It seems to be a fairly
> long-standing bug, dating to sometime around 1.6:
>=20
> 1.4.1/i386: no bug
> 1.4T+/sparc: no bug
> 1.4T+/i386: no bug
> 1.5.3/i386: no bug
> 1.6.1/i386: bug

UBC did it, I bet. Before we kept file data in the buffer cache and=20
hand-rolled the mapping page each time. With UBC, we keep the page for the=
=20
small file around, and we only zero out the end when we build the page=20
from disk rather than when we map it.

> 2.0/i386: bug
> 3.0/i386: bug
> 3.1/alpha: bug

The one issue we would need to keep track of in "fixing" this issue is=20
that we don't clobber something that's in the process of extending the=20
file.

Take care,

Bill

--CUfgB8w4ZwR/yMy5
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (NetBSD)

iD8DBQFGqDfhWz+3JHUci9cRAjCEAJsFiN7k2vdCG+r3djXgIXEoorQNUwCfex2B
kU1vWnCdNse7xkLRZwU04Mk=
=0zzL
-----END PGP SIGNATURE-----

--CUfgB8w4ZwR/yMy5--