Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S264759AbUD1MLU (ORCPT ); Wed, 28 Apr 2004 08:11:20 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S264767AbUD1MLT (ORCPT ); Wed, 28 Apr 2004 08:11:19 -0400 Received: from thunk.org ([140.239.227.29]:48825 "EHLO thunker.thunk.org") by vger.kernel.org with ESMTP id S264759AbUD1MLR (ORCPT ); Wed, 28 Apr 2004 08:11:17 -0400 Date: Wed, 28 Apr 2004 08:10:09 -0400 From: "Theodore Ts'o" To: Nigel Cunningham Cc: Chris Friesen , Jurriaan , linux-kernel@vger.kernel.org Subject: Re: What does tainting actually mean? Message-ID: <20040428121009.GA2844@thunk.org> Mail-Followup-To: Theodore Ts'o , Nigel Cunningham , Chris Friesen , Jurriaan , linux-kernel@vger.kernel.org References: <20040428042742.GA1177@middle.of.nowhere> <408F3EE4.1080603@nortelnetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.5.1+cvs20040105i Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2213 Lines: 42 On Wed, Apr 28, 2004 at 03:18:35PM +1000, Nigel Cunningham wrote: > On Wed, 28 Apr 2004 01:19:32 -0400, Chris Friesen > > >There has already been a case mentioned of a binary module that messed > >up something that was only visible once that module was unloaded and > >another one loaded. It all depends totally on usage patterns. > > I don't know what module you're talking about, but surely there must be > something that could be done kernel-side to protect against such problems. > Reference counting or such like? I guess if it was a hardware issue, but > then again that might be an issue with too many assumptions being made > about prior state? Maybe I am being too naive :> The problem is with corrupted data structures, pointers, etc. An evil/incompetently written driver can screw up data structures long after it has been unloaded. Historically, there was a time when a certain set of propeitary six-letter video company beginning with 'N' and ending with 'a' had serious bugs which would corrupt the kernel and create random kernel panics far removed from the actual source of the problems. Stack overflows in a badly written device driver can overwrite task structures and cause apparent filesystem problems which are blamed on the hapless filesystem authors instead of where the blame properly lies, namely the device driver author. The thing we could do kernel-side is to implement full VM protections. This is the microkernel approach; the problem though is the performance overhead of having to go through protection boundaries, setting up kernel-module-specific VM page tables, etc., etc. At some level, if people could implement these propeitary code bases in userspace, then there would be no need to risk corrupting internal data structures, and no need to "taint" the kernel. But usually there are performance reasons why the driver authors choose not to go down that path. - Ted - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/