From mint-bounce@lists.fishpool.fi Tue Dec 21 12:47:18 2004 X-Original-To: fnaumann@mail.boerde.de Delivered-To: fnaumann@mail.boerde.de Message-ID: <41C80CFC.60203@gabo.pl> Date: Tue, 21 Dec 2004 12:46:04 +0100 From: Adam Klobukowski User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: pl, en-us, en MIME-Version: 1.0 To: mint@fishpool.com Subject: Re: [MiNT] Kernel modules idea References: <41C7EFA5.6080404@gabo.pl> <41C80292.4010805@gabo.pl> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-ecartis-version: Ecartis v1.0.0 Sender: mint-bounce@lists.fishpool.fi Errors-To: mint-bounce@lists.fishpool.fi X-original-sender: atari@gabo.pl Precedence: bulk List-help: List-unsubscribe: List-Id: X-List-ID: X-Virus-Scanned: by amavisd-new at relay.boerde.de X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on relay.boerde.de X-Spam-Status: No, hits=-1.0 tagged_above=-50.5 required=3.8 tests=BAYES_00 X-Spam-Level: Frank Naumann napisa=C5=82(a): > Hello! >=20 >>> 1) a buggy kernel module can crash the kernel in the same way >>> as any other buggy kernel routine anyway >> >> >> If module will corrupt kernel memory - yes. But does whole kernel need= =20 >> to be killed when module makes wrong kfree()? >=20 >=20 > Yes. The problem is you don't know the reason. You even answered this=20 > yourself: >=20 > " ... If module will corrupt kernel memory - yes. ... " >=20 > So, how about this: a kernel module corrupt memory, for example kmalloc= =20 > internal data. On the next call of kfree() the kmalloc code see that th= e=20 > data structures are destroyed - what the can do now except halting the=20 > kernel? Nothing. But if user have AES and vconsoles (lets imagine we'll have=20 vconsoles in the future) and AES will do wrong kfree() do we have to=20 halt everything? > Additionally if a kernel module have such a bad failure you will see=20 > this during development. Such bugs don't live very long. So the chance=20 > to encounter such a bug from which you can recover is very, very small. I'm sill young (25 actually) but I've never seen an aplication that had=20 all bugs spotted on developemnt/testing stage. >>> 2) tracking resource usage will be a never ending story at this level >>> you will for sure oversee tons of dependency thus introducing(!)=20 >>> lot of >>> new bugs instead removing bugs >> >> >> I thought about it only becouse we would need to do cleanup when we=20 >> kill module - the same thing we do when we kill a process. >=20 > I don't think it make much sense to try to recover from such failures.=20 > First the dependencies will guide into a hell. Second, the chance to=20 > encounter a bug from which you can recover is very small as explained=20 > above. It's much more realistic that you have a real bad bug from which= =20 > you can't recover. What dependencies? Module dependencise? I do nto think we'll have much=20 module dependecies. > So why add lot of new code (with lot of new bugs) to try to recover fro= m=20 > a situation that most likely don't happen. And even if it happen the ne= w=20 > bugs of the new code will stop you :-) >=20 >>> 3) such fatal bugs you are able to detect are fixed in a short time >>> (bugs you can detect are maybe wrong API usage or such simple thin= gs) >> >> >> Better safe the sorry. >=20 >=20 > That's why there are lot of assert's in the kernel api routines to=20 > verify the right usage. If a kernel programmer do something wrong he=20 > will see it on the next test. Assert is one way path. No way to recover. That is proper if kenrel=20 really can't continue, but if there is a wey to recover - we shouldn try. >> Personally I trust no code. I just have hope ;). Speaking seriously:=20 >> the more code executes in kernel space, the more bugs we have in=20 >> kernel space becouse there is no program without bugs. >=20 >=20 > And you want to add lot of new code for a very trickily and sensitive=20 > recovering mechanism that isn't helpful in most cases. Better safe then sorry ;) --=20 Semper Fidelis Adam Klobukowski atari@gabo.pl