Re: patch for ATAng bug

From: David Gilbert <dgilbert_at_dclg.ca>
Date: Mon, 8 Sep 2003 07:07:05 -0400
>>>>> "Soren" == Soren Schmidt <sos_at_spider.deepcore.dk> writes:

Soren> It seems David Gilbert wrote:
>> I submitted kern/56572 a few minutes ago.  It patches ata-disk.c to
>> reject a disk that has zero blocks.
>> 
>> This is a good thing ... malicious or broken disks (compact flash,
>> whatever) shouldn't crash machines.
>> 
>> But in this case, the detected ad3 doesn't exist.  The machine is a
>> laptop with a drive on channel 0 and a DVD+R on channel 1.  If the
>> DVD is removed, the phantom ad3 doesn't show up, either.
>> 
>> ... so that issue with ATAng is unresolved.

Soren> Uhm, I'm working on finding the real problem, and I'd like that
Soren> to be the solution. However the above may be a good workaround
Soren> for those bitten by this...

Well... is it not possible for malicious hardware to claim to have
zero blocks (by claiming one of it's parameters is zero)?  Obviously
it is now.  Some of the other crashing complaints (complaints of
crashing only without media in a zip drive, for instance) seem
similar.

I agree that the real problem in my instance is that the phantom drive
shows up.  If I can be any help on that issue, I'd be happy to boot
test code.

But my question is: would the same parameters passed to ad_print()
result from a pathalogical device (a broken compact flash, hard disk
or whathaveyou)?  I put the fix in ad_attach() because I felt that
some other code might break ... but shouldn't we at least protect the
divide-by-zero ... or better reject devices of size zero at this
point.  I can't imagine that zero sizes devices are very useful for
storing things.

Dave.

-- 
============================================================================
|David Gilbert, Independent Contractor.       | Two things can only be     |
|Mail:       dave_at_daveg.ca                    |  equal if and only if they |
|http://daveg.ca                              |   are precisely opposite.  |
=========================================================GLO================
Received on Mon Sep 08 2003 - 05:40:21 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:21 UTC