Date: Wed, 02 Dec 1998 00:41:15 -0800 From: Mike Smith <mike@smith.net.au> To: Bruce Evans <bde@zeta.org.au> Cc: mike@smith.net.au, andyf@speednet.com.au, freebsd-current@FreeBSD.ORG, geoffb@demon.net, johan@granlund.nu, ortmann@sparc.isl.net Subject: Re: sio breakage Message-ID: <199812020841.AAA05456@dingo.cdrom.com> In-Reply-To: Your message of "Wed, 02 Dec 1998 17:35:01 %2B1100." <199812020635.RAA13376@godzilla.zeta.org.au>
next in thread | previous in thread | raw e-mail | index | archive | help
> >> something()
> >> {
> >> asm("cli");
> >> asm("sti");
> >> }
> >>
> >> This disables interrupts for 0 user instructions, but if a pagefault
> >> occurs for reading the "sti" instruction, it disables interrupts for
> >> hundreds, thousands or millions of kernel instructions.
> >
> >Since 'cli' can't be executed in user space, and a page fault in kernel
> >mode is a fatal occurrence, this can't happen.
>
> 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).
However:
dingo:/tmp>man 4 io
Formatting page, please wait...Done.
IO(4) FreeBSD Kernel Interfaces Manual (i386 Architecture) IO(4)
NAME
io - I/O privilege file
DESCRIPTION
The special file /dev/io is a controlled security hole that allows a pro-
cess to gain I/O privileges (which are normally reserved for kernel-
internal code). Any process that holds a file descriptor on /dev/io open
will get its IOPL bits in the flag register set, thus allowing it to per-
form direct I/O operations. This can be useful in order to write user-
land programs that handle some hardware directly.
The entire access control is handled by the file access permissions of
/dev/io, so care should be taken in granting rights for this device.
Note that even read/only access will grant the full I/O privileges.
FILES
/dev/io
SEE ALSO
mem(4)
HISTORY
The io file appeared in FreeBSD 1.0.
BSD Jan 1, 1996 1
There is no reference to manipulating interrupt state here.
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).
If it is, it would require interrupts to be enabled for most of the
duration, which kinda defeats the entire issue...
--
\\ Sometimes you're ahead, \\ Mike Smith
\\ sometimes you're behind. \\ mike@smith.net.au
\\ The race is long, and in the \\ msmith@freebsd.org
\\ end it's only with yourself. \\ msmith@cdrom.com
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199812020841.AAA05456>