Return to BSD News archive
Newsgroups: comp.os.386bsd.bugs Path: sserve!newshost.anu.edu.au!munnari.oz.au!network.ucsd.edu!usc!cs.utexas.edu!sun-barr!decwrl!access.usask.ca!kakwa.ucs.ualberta.ca!acs.ucalgary.ca!cpsc.ucalgary.ca!xenlink!fsa.ca!deraadt From: deraadt@fsa.ca (Theo de Raadt) Subject: Re: my bug list In-Reply-To: terry@cs.weber.edu's message of Tue, 30 Mar 93 21: 50:55 GMT Message-ID: <DERAADT.93Apr12004947@newt.fsa.ca> Sender: news@fsa.ca Nntp-Posting-Host: newt.fsa.ca Organization: little lizard city References: <DERAADT.93Mar26160807@newt.fsa.ca> <1993Mar29.142429.12369@cm.cf.ac.uk> <1993Mar29.144932.23840@uvm.edu> <1993Mar30.215055.21172@fcom.cc.utah.edu> Date: Mon, 12 Apr 1993 07:49:47 GMT Lines: 53 In article <1993Mar30.215055.21172@fcom.cc.utah.edu> terry@cs.weber.edu (A Wizard of Earth C) writes: Theo points out [ in a later posting ] that one can cause the card to generate an interrupt. This won't necessarity work if other interrupts are occurring at the same time (like a COM card or a printer card might be causing if the boot is a result of power on and a slow printer or modem is still resetting (an outgrowth of not disabling any interrupts during boot)... and that "false interrupt" occurs at a potentially valid location for the card currently being probed for. Trivial. Disable interrupts you don't care about in the PIC. Enable them when the config process has finished. Wait, did I mention "trivial" ? Multiple cards also present a problem; even if identified, you can't tell the difference between "card A at port a + card B at port b" and "card A at port b + card B at port a". This is more of a problem with the current system than what I'm suggesting. Under the new system, if there is a conflict, one will get picked. The other one won't show up at all. There is also the issue, not yet discussed, of shared interrupts; for instance, I might have two Control Systems Hostess boards in the same machine sharing IRQ 4. Identification of which card caused the interrupt is done by asking the card. This is fine if the cards sharing the interrupt are homogenous and can use the same method; what if they aren't? A probe routine can't be guaranteed of the source of the interrupt if it's shared, for instance, between a multiport com card like the Hostess and some other [non-Hostess] device. You're not allowed to share interrupts on the ISA bus. It is *illegal*. The hardware is not designed for it. (rgrimes sez totem pole vs. open collector.) In either of the above two cases, simply stopping when one card is identified is not sufficient to get both cards working, nor is a single pass sufficient to identify al hardare sharing interrupts. Bull pucky. I don't think the problem of autoconfiguration, at least on an ISA bus, yields 100% to any potential attack; we are going to have to continue providing static configuration information to all but a small subset of all devices. yeah right.. who cares about 100% as long as it's better than what we're using now. <tdr. (a good configuration file has lots of ? in it) <tdr. -- This space not left unintentionally unblank. deraadt@fsa.ca