Conley%csvax.cs.ukans.edu@RELAY.CS.NET (03/10/87)
system: 780, 4.3 Well, a couple of us here have been mucking with a system call ( vhangup, although that's not terribly important ). So we've tweaked the sysent array, and added one of those mysterious struct a's to the code. Now, one parameter is a string, and we use uap->string just like any other string ( e.g. in a tprintf ). However, an associate insists that this cannot be done, i.e. the string exists in user space ( and this is kernel mode, hence kernel address space ). "Gotta do a copyin". Dispensing with what we do ( and don't! ) know about the u area, kernel stack, ( etc, etc ), how come our not doing this particular copyin doesn't provoke crash and burn mode? The code works, we can print the silly thing, yet it shouldn't work ( or should it? ). Would anyone care to shed some light on this? Thanks for your time and patience. Dennis Conley Computer Science Dept University of Kansas CSNET: conley@csvax.cs.ukans.edu conley@ukans.csnet ( previously ) BITNET: conley@ukanvax "Onward through the fog!"
ron@BRL.ARPA (Ron Natalie) (03/10/87)
Sure, on a 780, the user space of the current process is mapped in at that stage in system call executions. You only need to do the copyin/out when you want to get at user data asynchronously (i.e. u does not reference the process you are referring to) or if your machine architecture is such that you don't map the USER space when the kernel is executing. -Ron
chris@mimsy.UUCP (03/10/87)
In article <4838@brl-adm.ARPA> Conley%csvax.cs.ukans.edu@RELAY.CS.NET writes: >Well, a couple of us here have been mucking with a system call ... >one parameter is a string, and we use uap->string just like any other string >(e.g. in a tprintf). However, an associate insists that this cannot be >done, i.e. the string exists in user space (and this is kernel mode, hence >kernel address space). He is right. However, user space and kernel space are not mutually exclusive, not on a Vax. Kernel code can look in user space if it wants to. If, however, the `string' is a wild pointer, the machine will crash: main() { new_syscall((char *) 0xc0000000); /* NOTREACHED */ } >"Gotta do a copyin". Not necessarily. The routine for dealing with C strings in user space is `copyinstr', but some other part of the kernel may be doing that already (e.g., namei). -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690) UUCP: seismo!mimsy!chris ARPA/CSNet: chris@mimsy.umd.edu
narayan@twg-ap.UUCP (03/11/87)
In article <4838@brl-adm.ARPA>, Conley%csvax.cs.ukans.edu@RELAY.CS.NET writes: > system: 780, 4.3 > > "Gotta do a copyin". > > Dispensing with what we do ( and don't! ) know about the u area, kernel > .... > > Would anyone care to shed some light on this? This would work on a VAX where the kernel address space begins with the high order bit turned on. But if you go to some other machine where it is not possible to distinguish between kernel space and user space, then this string will be treated to be in the kernel area. They you may crash and burn. You really need to to do a uchar(I think) not a copy in to load the string in (after setting u.u_xxx). -- Narayan Mohanram Phone: 415-962 7170 ARPANET twg-ap!narayan@lll-tis-b.ARPA Usenet {attunix, ihnp4}!amdahl!twg-ap!narayan USnail The Wollongong Group 1129 San Antonio Road Palo Alto, CA 94303. USA ========================================================= || If you can't lick it, try some whipped cream || =========================================================
amos@instable.UUCP (03/11/87)
When in kernel mode on a VAX, you have both kernel and user spaces mapped, since they do not overlap virtually. Copyin/copyout do not use special instructions, but they do sanity checks without which a mistake by a user might crash the system. (A side effect of this is that the u struct is accessible from user mode, although read-only). -- Amos Shapir National Semiconductor (Israel) 6 Maskit st. P.O.B. 3007, Herzlia 46104, Israel (011-972) 52-522261 amos%nsta@nsc.com 34.48'E 32.10'N
willcox%mycroft@gswd-vms.arpa (03/11/87)
I don't think that Ron Natalie has it quite right about where you can
or must use copin/out.
1) No version of copyin/out that I've seen will work for other than
the current process. In other words, you can't use it from
interrupt code, nor to copy data to/from another process.
2) On lots of machines, the current process is mapped while you are
processing a system call. However, one of the jobs of copyin/out
even on these systems is to ensure that the user has legal access
to the area of memory in question. They prevent the kernel from
getting a segmentation fault and from copying over its own area
when the user gives it a bogus pointer. For this reason, you MUST
(a moral, if not physical requirement) use copyin/out (or fuword,
uiomove on BSD, etc.) to access user space. If you have a case
where you are sure that you can blindly use a pointer supplied from
user space, then I can write a program that will crash your system.
David A. Willcox
Gould CSD-Urbana
1101 E. University Ave.
Urbana, IL 61801
217-384-8500
UUCP: {decvax,ihnp4}!uiucdcs!ccvaxa!willcox
ARPA: willcox@gswd-vms.arpachris@mimsy.UUCP (03/12/87)
In article <157@twg-ap.UUCP> narayan@twg-ap.UUCP (Narayan Mohanram) writes: >... if you go to some other machine where it is not possible to >distinguish between kernel space and user space, ... you may crash >and burn. Right. >You really need to to do a uchar(I think) not a copy in to load the >string in (after setting u.u_xxx). No: namei used to call uchar to read from user I or D space, one byte at a time. One would set u.u_segflg according to the source space (user instruction, user data, or system), and namei and a few other routines would call uchar or schar. I am not old enough to be familiar with just which routines were done which way in which kernels, but in 4.3, the routine to copy strings in is `copyinstr'. Incidentally, the 4.3 copy routines have been adapted to 2.10BSD, speeding it considerably. A function call per character for every name lookup is just a bit too much overhead. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690) UUCP: seismo!mimsy!chris ARPA/CSNet: chris@mimsy.umd.edu
ccplumb@watnot.UUCP (03/12/87)
In article <713@instable.UUCP> amos%nsta@nsc.com (Amos Shapir) writes: >When in kernel mode on a VAX, you have both kernel and user spaces mapped, >since they do not overlap virtually. Copyin/copyout do not use special >instructions, but they do sanity checks without which a mistake by a user >might crash the system. > >(A side effect of this is that the u struct is accessible from user mode, >although read-only). Does anyone know if this feature is available on a Sun 3? Where would I look in memory (from the user process)? (I can probably find this myself, but) which include file holds the relavent documentation? Thanks in advance for all hints received. -Colin Plumb (ccplumb@watnot.UUCP) Zippy says: With YOU, I can be MYSELF.. We don't NEED Dan Rather..