Date: Sun, 31 Dec 1995 08:02:52 -0500 (EST) From: Sujal Patel <smpatel@wam.umd.edu> To: Joerg Wunsch <joerg_wunsch@uriah.heep.sax.de> Cc: FreeBSD hackers <freebsd-hackers@freebsd.org> Subject: Re: /dev/io Message-ID: <Pine.BSF.3.91.951231075804.1395A-100000@sl-015.sl.cybercomm.net> In-Reply-To: <199512310841.JAA16189@uriah.heep.sax.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 31 Dec 1995, J Wunsch wrote: > I don't think that this would be more secure than our scheme anyway. > So although it seems to be more `standard', there's nothing we would > gain from another scenario. Given that it doesn't have any technical > merit at all, i wonder why NetBSD even adopted it. I can't say for sure why NetBSD would have adopted it, but I'm not even sure that they have KDENABIO (anymore?) because I couldn't find it in any of their 1.1A-- As far as I can tell the only way in NetBSD is i386_iopl and friends. This could be because NetBSD supports so many different architectures; IOPL is a pretty architecture dependant function and maybe /dev/io is a bit too generic for them. > Our KDENABIO is restricted to a process with effective UID 0. Our > /dev/io is a security hole in that it allows group kmem processes to > access the registers (and i haven't seen any reason why this might be > necessary or useful). I haven't heard any reason why /dev/io is useful or necessary either :) It seems that just about everything uses KDENABIO to gain IO priviledge. > I think SysV allows any process to get access to IO registers via the > IO perm bitmap. :-( > > (I don't know about Linux.) Linux enforces euid 0 credentials on both ioperm() and iopl(). In Linux, you have a small IO permission bitmap (for ports 0-0x3ff) and then you have to use iopl() to gain access to the rest. Sujal
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.91.951231075804.1395A-100000>