Return to BSD News archive
Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!agate!howland.reston.ans.net!paladin.american.edu!news.univie.ac.at!fstgds15.tu-graz.ac.at!fstgds01.tu-graz.ac.at!not-for-mail
From: chmr@edvz.tu-graz.ac.at (Christoph Robitschko)
Newsgroups: comp.os.386bsd.bugs
Subject: Re: copyout family fixed
Date: 17 May 1993 17:06:26 +0200
Organization: Technical University of Graz, Austria
Lines: 57
Message-ID: <1t89liINN6si@fstgds01.tu-graz.ac.at>
References: <WS.93May14165515@kurt.tools.de>
NNTP-Posting-Host: fstgds01.tu-graz.ac.at
X-Newsreader: TIN [version 1.1 PL7]
In article <WS.93May14165515@kurt.tools.de> Wolfgang Solfrank (ws@tools.de) wrote:
> While the bug analysis is correct, the fix is a bit overly complicated.
>
> Especially the case where data is transferred from user space into
> kernel space can be fixed more easily. Simply use the user data
> segment descriptor and the 386 will not allow access to kernel
> memory even though it runs in kernel mode.
As you may have guessed, I am no 386 guru, and I've tried to keep the
segmenting stuff as far away from me as I could.
I thought all the segments were set to the same (start at 0 and be 4GB in
size), but I now see it is different.
> The case where the transfer is the other way around is a bit
> more complicated. This is essentially a design bug in the 386
> (and is, to the best of my knowledge, fixed in the 486), namely
> that the protection check by using the user segment descriptors
> is not propagated to the page level.
As far as I know, the 486 has extra bits in the PDEs/PTEs to support
r/o memory in kernel mode. I don't know whether these bits are enabled
in 386bsd or not.
>
> For the write case (transfer data from user to kernel) this
> is not a problem since there is no address where a kernel read
> is allowed and a user read isn't except the kernel data itself.
> But this can be (and is) protected on the segment level.
>
> For the read case (transfer data from kernel to user) there is
> an additional problem. While the destination page might be there
> it might be write protected to allow the correct function of
> the copy-on-write mechanism (and possibly allow the selective
> write protection of user memory (mprotect et.al.)). This requires
> the access check in the copyout routine for every page.
>
> Below are my own copyin/copyout and [fs]u{byte,sword,word} routines.
> Sorry, no context diffs, as my version is a heavily hacked locore.s
> from the original Net2 tape.
Is it legal for copyout to start copying and then fail in the midst ?
There are manual pages with sentences similar to this:
"-1 is returned and buf is not changed if any of the following is true:
[EFAULT] buf points to an illegal memory area"
select(2) is one example, I think I remember some ioctls as well.
This is the reason why I wrote my versions so that they first check
each page before starting the actual copy.
> ws@tools.de (Wolfgang Solfrank, TooLs GmbH) +49-228-985800
What makes me a bit angry is that you post your code now after someone
else has put significant effort (and it really was significant effort for
me) in this project. If you had published your work previously, we could
have concentrated on other work.
Christoph