Delivery-date: Tue, 15 Aug 2000 22:21:11 +0100 Received: from [193.195.224.3] (helo=internal.mail.demon.net) by singsing.eng.demon.net with esmtp (Exim 3.14 #1) id 13Oo91-0001jl-00 for michaelb@singsing.eng.demon.net; Tue, 15 Aug 2000 22:21:11 +0100 Received: by internal.mail.demon.net id WAA20803; Tue, 15 Aug 2000 22:20:47 +0100 (BST) Received: from finch-post-11.mail.demon.net (finch-post-11.mail.demon.net [194.217.242.39]) by internal.mail.demon.net with ESMTP id WAA20792; Tue, 15 Aug 2000 22:20:38 +0100 (BST) Received: from romana.davros.org ([194.217.240.35]) by finch-post-11.mail.demon.net with esmtp (Exim 2.12 #1) id 13Oo8T-0005sY-0B Message-ID: Date: Tue, 15 Aug 2000 20:45:03 +0100 From: "Clive D.W. Feather" Subject: Re: Security Initiative References: <010901c00395$4cab2970$cb38adc3@access.demon.net> In-Reply-To: MIME-Version: 1.0 X-Mailer: Turnpike Integrated Version 5.00 U <81yImECxEkLwWkbKTSiEkLA3nC> Precedence: bulk Content-Length: 2648 -----BEGIN PGP SIGNED MESSAGE----- In article , Simon Hewison writes >1770 DFS ARGH SCREAM. The disc interface chip from hell. True story: this got into a released operating system ROM that I was maintaining at the time, and it was a week of panic until tracked down. If you issue a "move to track N" command, the controller compares N with its track register and issues "move in" or "move out" commands as appropriate. It then reads the track number from the disc and checks it's in the right place. If it isn't, it updates the track register and tries again. Then it issues a SUCCESS or FAIL result code appropriately. Now and then the track register got corrupted (I forget why, but it was something to do with certain other operations). Suppose you're on track 40, you issue a "move to track 45" command, but the register says 50. The controller moves the head *out* 5 tracks, but when it reads the disc it sees "35", so it has another go, moves in 10 tracks, checks the result, and says SUCCESS. No problem. But if the register got a large number in it, the drive would step all the way out to track 0. When it got there, the drive raises the TRACK0 pin on the chip. This causes stepping to be stopped *and a zero to be written in the track register*. Wait for it ... The controller now reads the disc, sees it's on track zero, compares that with the track register, *AND ISSUES A SUCCESS CODE*. So you blithely go and write user data all over the directory track !! Thankfully, once I had teased this quirk out of the manual it was dead easy to fix. All that was necessary was to issue each move command twice. If the first one worked, the second one did nothing. If the first one ended on track zero, the second one took you to the right place. I forget why the register corruption wasn't a problem, but it wasn't. - -- Clive D.W. Feather | Internet Expert | Work: Tel: +44 20 8371 1138 | Demon Internet | Home: Fax: +44 20 8371 1037 | Thus plc | Web: Written on my laptop; please observe the Reply-To address -----BEGIN PGP SIGNATURE----- Version: PGPsdk version 1.7.1 iQEVAwUBOZmdvyNAHP3TFZrhAQEzNggAmLE8LpE5T5SGrT37tcGhGgAlLzrlX8Sq RS0RFgWH6Yw1Tsrp+7omTNNc16R9WAEOA33iOuEgPmkT9xaUeWAT4Gu1qag9Ys6I Yutifi/2Pgk1b1ys0viBiaGye+MDpchKIw31xUtmgfWrTZ9CV6HS/JRPp2hz5qAK ldfixU1MVslf/kFpQzLJD61NIhykVctwUQ5LfLIvS+/3YNBMxZtS1C6tpGpVGzmF GGaw2PUjvERimfCruhhnUMiwhez+5a0fCfHNf0eJdj+kRhXyj3OnXwTg8u5HesWN 48Q7vUWCNX9kYKU67UBZiA+xPSwSzd7AtDB/JHriHUPuO/etmWFYfA== =dE8D -----END PGP SIGNATURE-----