Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Tue, 12 Mar 2002 06:24:40 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Tue, 12 Mar 2002 06:24:21 -0500 Received: from [195.63.194.11] ([195.63.194.11]:56583 "EHLO mail.stock-world.de") by vger.kernel.org with ESMTP id ; Tue, 12 Mar 2002 06:24:09 -0500 Message-ID: <3C8DE4CC.9060302@evision-ventures.com> Date: Tue, 12 Mar 2002 12:21:48 +0100 From: Martin Dalecki User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020205 X-Accept-Language: en-us, pl MIME-Version: 1.0 To: Jeff Garzik CC: Linus Torvalds , andersen@codepoet.org, Bill Davidsen , LKML Subject: Re: [patch] My AMD IDE driver, v2.7 In-Reply-To: <3C8D692B.7070508@mandrakesoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Jeff Garzik wrote: > Linus Torvalds wrote: > >> >> On Mon, 11 Mar 2002, Jeff Garzik wrote: >> >>> You have convinced me that unconditional filtering is bad. But I still >>> think people should be provided the option to filter if they so desire. >>> >> >> Hey, choice is always good, except if it adds complexity. >> >> The problem with conditional filtering is that either it is a boot (or >> compile time) option, or it is a dynamic filter. >> > heh, I couldn't have given a better argument against a dynamic filter. > > I was actually assuming the filter would be a compile-time option, for > security's sake. Boot-time option works too. > > So, it sounds like you could be sold on an fixed-at-compile-time filter > that can be disabled at boot :) I know you don't like > fixed-at-compile-time as you mentioned, but it's my argument there is a > class of users that definitely do. MandrakeSoft would likely enable the > filter in the "secure" kernel and disable it in the "normal" kernel, for > example. Mandrake Soft should disable the whole sidestepping ioctl - even the generic one - in a secure kernel. Filtering them all to -EINVAL is the bast one can do for *security*. The stuff which is not should be implemented with generic ioctl with a proper sementics. Rings a bell? No matter how you turn it it turns out that the taskfile stuff as it is is just useless - formal verification inside the kernel can be done at coding time. Formal verification for vendor specific stuff can be done in user land. Formal verification for security stuff doens't make sense, becouse the whole interface doesn't make sense for security concerns. Formal verification of the commands for political reasons is just plain naive... - 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/