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: <20090312022825.44571.qmail@web4106.mail.ogk.yahoo.co.jp>
Date:	Thu, 12 Mar 2009 11:28:25 +0900 (JST)
From:	Norman Diamond <n0diamond@...oo.co.jp>
To:	Robert Hancock <hancockrwd@...il.com>
Cc:	Alan Cox <alan@...rguk.ukuu.org.uk>, linux-kernel@...r.kernel.org,
	linux-ide@...r.kernel.org, n0diamond@...oo.co.jp
Subject: Re: Off-by-one in both LIBATA and IDE drivers

Robert Hancock wrote:
> Norman Diamond wrote:
>> Alan Cox wrote:
>>> Norman Diamond wrote:
>>>
>>>> It looks like both LIBATA and the old IDE drivers
>>>> have an off-by-one error in deciding whether to
>>>> use READ SECTOR(S) instead of READ SECTOR(S) EXT.
>>>
>>> This was fixed some time ago, you need a newer
>>> kernel.
>> 
>> Well, either that or I need an older kernel.  It
>> was also fixed in 2.6.20, for which I think there
>> was a ready-made Slax distribution.
>> 
>> On another topic, trying 2.6.20 in whatever Slax
>> distribution it was, an Intel ICH7M had DMA
>> enabled on both /dev/hda and /dev/hdc.  I
>> understand that [subsequent changes losing DMA]
>> is considered to be by design not a bug.
> 
> You really shouldn't use the IDE drivers with SATA
> devices, if that's what you're talking about as far
> as the previous behavior. They were really never
> designed for it.

There's next to nothing that I can do about it.
If the BIOS sets the Intel chip to present an ATA
interface then the IDE drivers take control early in
the boot process.  If the BIOS sets the Intel chip to
present a SATA interface then LIBATA takes control
early in the boot process.

I'm considering constructing a boot menu where the
default command line has hda=noprobe hdb=noprobe
hdc=noprobe hdd=noprobe, and an alternate boot option
omits those.  Even if this will be reliable enough, it
won't be easy to explain to customers (if you don't
believe that then read some tech support stories).

> Realistically, although some people still work on
> it, testing coverage of the old IDE drivers is not
> that great these days, since most distributions no
> longer use it.

Even Knoppix 6.0.1, whose kernel isn't too antique
yet, assigned /dev/hda and /dev/hdc on my Dell D820
with ICH7M.

--------------------------------------
Power up the Internet with Yahoo! Toolbar.
http://pr.mail.yahoo.co.jp/toolbar/
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ