From owner-freebsd-hackers Fri Nov 7 06:27:41 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id GAA01675 for hackers-outgoing; Fri, 7 Nov 1997 06:27:41 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from phoenix.its.rpi.edu (phoenix.its.rpi.edu [128.113.161.45]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id GAA01666 for ; Fri, 7 Nov 1997 06:27:35 -0800 (PST) (envelope-from dec@phoenix.its.rpi.edu) Received: from localhost (dec@localhost) by phoenix.its.rpi.edu (8.8.7/8.8.7) with SMTP id JAA07866; Fri, 7 Nov 1997 09:27:22 -0500 (EST) (envelope-from dec@phoenix.its.rpi.edu) Date: Fri, 7 Nov 1997 09:27:22 -0500 (EST) From: "David E. Cross" To: Christoph Kukulies cc: freebsd-hackers@freefall.FreeBSD.org Subject: Re: root - can root do an asm("cli")? In-Reply-To: <199711070955.KAA27835@gil.physik.rwth-aachen.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Fri, 7 Nov 1997, Christoph Kukulies wrote: > > Is there a difference between what the kernel can do vs. what > a root process can do with regard to priviliged instructions? > > In particular: can a root process do an asm("cli"); and thus > block the whole system? I tried once under FreeBSD > and got a bus error. May be the cause was a differnet one but > when I got that bus error I thought: "Hmm, fine, so there > is something running at a different ring which prevents root > from doing such malign things" and was feeling safe. > > Now someone tells me, root can do everything and can even do > that. No, root cannot do 'everything'. 'root' is subject to the same rules that other processes are (it cannot access outside its memory bounds, it cannot take the processor, etc...). The difference is that 'root', (uid 0 actually), has access to certain Kernel calls (even the Kernel is bound to the memory protection, although the kernel can change the protection as it needs to), which allow it to do more, ie. root cannot access memory it doesn't own, but it has access to /dev/mem and /dev/kmem, which means it *could* access it indirectly. I hope that helps some. -- David Cross