From owner-freebsd-questions Mon Oct 28 14:38:03 1996 Return-Path: owner-questions Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA08462 for questions-outgoing; Mon, 28 Oct 1996 14:38:03 -0800 (PST) Received: from nrtc.nrtc.northrop.com (nrtc.northrop.com [128.99.0.1]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id OAA08450 for ; Mon, 28 Oct 1996 14:37:59 -0800 (PST) From: johnson@charming.nrtc.northrop.com Received: from charming.nrtc.northrop.com by nrtc.nrtc.northrop.com id aa02657; 28 Oct 96 14:13 PST Received: from charming.nrtc.northrop.com by charming.nrtc.northrop.com (4.1/SMI-4.1.1) id AA07533; Mon, 28 Oct 96 14:37:50 PST Message-Id: <9610282237.AA07533@charming.nrtc.northrop.com> To: questions@freebsd.org Subject: Why is PSL_VM excluded from USERCHANGE macro? Date: Mon, 28 Oct 96 14:37:49 PST Sender: owner-questions@freebsd.org X-Loop: FreeBSD.org Precedence: bulk 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