From owner-freebsd-current Wed Dec 2 01:27:16 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id BAA28712 for freebsd-current-outgoing; Wed, 2 Dec 1998 01:27:16 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from alcanet.com.au (border.alcanet.com.au [203.62.196.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id BAA28707 for ; Wed, 2 Dec 1998 01:27:13 -0800 (PST) (envelope-from peter.jeremy@auss2.alcatel.com.au) Received: by border.alcanet.com.au id <40351>; Wed, 2 Dec 1998 20:26:17 +1100 Date: Wed, 2 Dec 1998 20:26:51 +1100 From: Peter Jeremy Subject: Re: sio breakage To: mike@smith.net.au Cc: current@FreeBSD.ORG Message-Id: <98Dec2.202617est.40351@border.alcanet.com.au> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Mike Smith writes: >> man 4 io. > >Having run the test program I used to check this as root, I see that it >is indeed possible (although it should not be). As stated in io(4), FreeBSD allows a process to execute I/O instructions by changing IOPL to allow a ring-3 (user) task to perform I/O. For reasons known best to Intel(*), CLI, STI and changing the IF using POPF are controlled by IOPL, rather than being ring-0 instructions (like the other privileged instructions). An alternative approach would be to leave IOPL at 0 and use the I/O Permission bitmap in the TSS. This allows I/O without allowing CLI/STI. The disadvantage is that either you have a per-process TSS (which is expensive in memory), or the TSS needs to be re-written on a context switch (which is expensive in time). BSDI (at least BSDI 1.1) used this approach - but the bitmap was system-wide, so enabling an I/O port for any process enabled it for all processes (which isn't particularly secure). [And at least on 486's, I/O instructions are much slower is the IOPB is used instead of IOPL - even slower than accessing the ISA bus :-(]. (*) The need to atomically issue multiple I/O instructions could be seen to be a justification for this. >There is no reference to manipulating interrupt state here. I agree that io(4) should mention this. >I'm still somewhat at a loss as to how it's meant to be possible for the >page fault you posit to be handled in the case where PSL_I is cleared in >all cases (eg. disk drivers with no interrupt timeout handlers). There are occasional CLI/STI pairs in the kernel. Presumably an STI gets executed somewhere along the line... Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message