linux-kernel - Re: No IDE drivers loaded for Toshiba Satellite 320 CDS

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <48053AD1.8010007@gmail.com>
Date:	Wed, 16 Apr 2008 08:31:29 +0900
From:	Tejun Heo <htejun@...il.com>
To:	Lennart Sorensen <lsorense@...lub.uwaterloo.ca>
CC:	Alan Cox <alan@...rguk.ukuu.org.uk>, Frans Pop <elendil@...net.nl>,
	linux-ide@...r.kernel.org, linux-kernel@...r.kernel.org,
	Bartlomiej Zolnierkiewicz <bzolnier@...il.com>
Subject: Re: No IDE drivers loaded for Toshiba Satellite 320 CDS

Hi,

Lennart Sorensen wrote:
> Yes.  After all you would quickly see a problem if you built a kernel
> with all the IDE drivers built in, which some people do.  In that case
> ide generic is always activated last and anything bad that would happen
> with loading a module would happen built in too.

Yeah, pick the right configuration.  You can make it malfunction.

> I think it is the wrong place to worry about problems.  If a native
> driver takes control of a chip, it is that drivers responsibility to
> reserve any relevant ports on that chip sufficiently to prevent another
> driver from messing with it that doesn't know anything about that chip.
> If the native driver doesn't load at all, then ide-generic ought to try
> and drive the chip if it has legacy ports.

I'm not too sure whether that will be always possible and I'm less sure 
we'll get enough test coverage over this kind of stuff.

> So my opinion is that making life easy to those machines with legacy ide
> ports is a good thing, while trying to be overly paranoid about one
> driver potentially hitting a bug in another driver is just silly.  Why
> couldn't two native ide drivers potentially go looking for the same
> ports too?  Are you sure no native driver uses the legacy IDE port
> numbers to control a chip in native mode?  Finding bugs is good since
> then they can be fixed.  Trying to prevent hitting bugs (which shouldn't
> be there in the first place) doesn't seem useful.

Yeah, theoretically, you're right.  The problem is that what breaks when 
things go wrong.  If you don't probe generic ports by default, harddisks 
won't be detected on some legacy systems but you can always prompt the 
user about loading the generic driver.  If you probe generic ports by 
default, when things go wrong, you break modern machines in an 
unrecoverable (w/o reset) way.  I'd rather choose bothering the user on 
legacy machines.

thanks.

-- 
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/