Date: Mon, 23 Jun 1997 14:55:42 -0700 From: John-Mark Gurney <jmg@hydrogen.nike.efn.org> To: Terry Lambert <terry@lambert.org> Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: problem with /dev/zero and mmap?? Message-ID: <19970623145542.29255@hydrogen.nike.efn.org> In-Reply-To: <199706231748.KAA00960@phaeton.artisoft.com>; from Terry Lambert on Mon, Jun 23, 1997 at 10:48:48AM -0700 References: <19970623030040.50241@hydrogen.nike.efn.org> <199706231748.KAA00960@phaeton.artisoft.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Terry Lambert scribbled this message on Jun 23:
> > well.. I was just experimenting with mmap and discovered that something
> > works when it shouldn't:
> >
> > fd=open("/dev/zero", O_RDONLY, 0);
> > base=mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0);
> > base[0]=4;
> >
> > the above won't cause a bus error.. but replace /dev/zero with a normal
> > file and it will fail as expected (with a Bus error)... shouldn't the
> > mmap behave the same?? if you try and write to the fd, it will set
> > errno to EBADF, just like the man page says...
> >
> > well... I am looking at sys/vm/vm_mmap.c, and it looks like that special
> > hack for SunOS (on line 228) is a bit to early... or does sunos require
> > that you be able to do the above?
> >
> > I know it's minor, but it encorages bad programming, and someone might
> > use code similar to the above and wonder why it stops working when they
> > switch to a normal file, or other char device...
>
> This use of /dev/zero is a "well known hack" for obtaining zero
> filled anonymous pages from swap.
yes... I read the comment, and I know how I hacked phkmalloc to get it
to work under Solaris... :)
> When you map pages from /dev/zero, you create a mapped page address
> range which, even though it is MAP_SHARED is local only to your
> process (you *can* cause child processes to inherit a shared
> copy of this region using rfork() to implement your "fork()"
> instead of calling it directly).
> The write succeeds because pages you mapped are not associated with
> the fd after the mapping.
no.. the write succeeds because the permission checking isn't done
early enough in the mapping process... didn't you look at the code
I sited??
> If things behaved as you wanted, there would be two possible
> consequences:
>
> 1) You would modify the contents of /dev/zero for other
> users of the device. This is not acceptable.
it's VERY obvious that you never read my complete message... because
if you had you would of read that ALL I propose was to move the test
of if it's /dev/zero to below the permission checking... I don't
propse anything else... if you want to look at the code yourself
(which I could send you the neccessary parts if your unable to use
the web to get a copy) lines 228-255 in file srcy/sys/vm/vm_mmap.c,
rev 1.64... (oh, I'm sorry but the previous stated line was one off
as I was using an older version, sorry if that confused you)
> 2) The mmap() would fail because of the conflict between
> O_RDONLY and PROT_WRITE.
yes.. this second one is what I want... you specificly opened the
file for read only access.. and that is what you should get... the
permissions on /dev/zero permit you to open it read/write so why
don't you??
> Either of these would render your request useless, since you
> can get "read-only zeros" much easier using memset()/mprotect().
I'm just pointing out a "usage" error that might encourage people to
do stupid things in the future... coming to use, it used to work, why
don't it contiue to work... and anybody stupid enough to expect to
write to a RDONLY descriptor needs to learn a bit more about
permissions...
Terry, PLEASE read the code I sited... this bit of code is SO easy to
understand, it isn't even funny...
--
John-Mark Gurney Modem/FAX: +1 541 683 6954
Cu Networking
Live in Peace, destroy Micro$oft, support free software, run FreeBSD
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19970623145542.29255>