Date: Mon, 28 Oct 96 14:37:49 PST From: johnson@charming.nrtc.northrop.com To: questions@freebsd.org Subject: Why is PSL_VM excluded from USERCHANGE macro? Message-ID: <9610282237.AA07533@charming.nrtc.northrop.com>
next in thread | raw e-mail | index | archive | help
My understanding is that when a user process receives a signal, processor state prior to reception of the signal is stored in the address space of the user process. Hence, during the handling of the signal the user could sneak in there and change the stored processor state. Then, on return from the signal handler the kernel would `restore' the sneakily modified processor state. In particular, the user could change the EFLAG value that had been saved. The kernel (in trap.c, I think) explicitly checks for this, and permits certain modifications to EFLAG. Modifications that are not allowed generate a segmentation violation or some such thing. There is a macro named something like PSL_USERCHANGE that has wired into it the EFLAG bits that the user is permitted to change. Examples would be the Carry and Zero condition code bits. My question: Why is PSL_VM excluded from the set that the user can modify? (If PSL_VM is set in EFLAG, the processor starts executing in Virtual 8086 mode.) What would the dangers be to system integrity if a user process started executing in Virtual 8086 mode? While the processor is executing in Virtual 8086 mode, the paging hardware still is enabled. It would appear that a user process operating in Virtual 8086 mode could do no harm to the kernel data structures or otherwise compromise the security of the machine. It might be useful to permit processes to operate in Virtual 8086 mode, for purposes of creating an operating environment to support execution of old 8086 code. Thanks, Greg Johnson johnson@nrtc.northrop.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9610282237.AA07533>