Date: Thu, 06 May 1999 14:24:01 -0400 From: "Christopher R. Bowman" <crb@ChrisBowman.com> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: John Baldwin <jobaldwi@vt.edu>, "Jordan K. Hubbard" <jkh@zippy.cdrom.com>, freebsd-current@FreeBSD.ORG, Studded <Studded@gorean.org> Subject: Re: How stable is -current? Message-ID: <199905061825.OAA07183@quark.ChrisBowman.com> In-Reply-To: <199905061734.KAA37651@apollo.backplane.com> References: <XFMail.990506111439.jobaldwi@vt.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
At 10:34 AM 5/6/99 -0700, Matthew Dillon wrote: >:I'll gladly test them. I'm in the process of upgrading the lab I run to 3.1 >:and it depends heavily on NFS. Since the lab is closed during finals I won't >:be losing massive amounts of data if they go wrong. Send 'em on. :) NFS is a >:big deal to a lot of us, and we'd like to see the changes MFC'd to -stable if >:possible. > > The only major bugfixes that have not been backported from -current to > -stable in regards to NFS are the NFS/TCP fix, which is being backported > now, and a number of fixes to the VM system when dealing with mmap(), > which cannot be backported until we backport the entire -current VM system. > Also, NFS-stable will break if directories are VMIO'd due to breakage > in the reconstitution of the valid range ( but directories are not VMIO'd > in either -stable or -current yet so this will not effect us yet ). > > The mmap() breakage is unavoidable in -stable but hopefully will not cause > serious problems for people. The breakage is related to garbarge showing > up in the mmap()'d pages *after* the logical file EOF. That is, if you > have a 500 byte file and mmap() it into a 4K page, data occuring after > offset 500 may or may not be 0. This sounds like the page is not being zeroed before being reassigned for other uses. Does this present a possible security problem? Might I get a page from a terminated process that wasn't zeroed? Say perhaps a page from a vipw process or something similar? If so, this really should be addressed at least in so far as to prevent any possible exploitation (ie putting out software with bugs is one thing, but putting out software with security holes is just bad, not that we are doing this, that's what I am asking) -------- Christopher R. Bowman crb@ChrisBowman.com http://www.ChrisBowman.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199905061825.OAA07183>