linux-kernel - Re: [PATCH 1/3] ide: add "ignore

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: <200905261932.43657.bzolnier@gmail.com>
Date:	Tue, 26 May 2009 19:32:43 +0200
From:	Bartlomiej Zolnierkiewicz <bzolnier@...il.com>
To:	Frans Pop <elendil@...net.nl>
Cc:	Alan Cox <alan@...rguk.ukuu.org.uk>, linux-ide@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/3] ide: add "ignore_hpa" module parameter

On Tuesday 26 May 2009 14:53:21 Frans Pop wrote:
> On Tuesday 26 May 2009, Bartlomiej Zolnierkiewicz wrote:
> > First time with the introduction of the default IDE HPA behavior of
> > always giving the access to the full capacity of a disk and leaving
> > decisions about HPA preservation/removal up to the installer & user.
> >
> > Second time when said distributions switched from IDE to libata (which
> > uses the different default behavior as it limits the capacity to
> > non-HPA part).
> 
> Has there really been something like a deliberate switch?

This heavily depends on distribution.

> In my experience with Debian there's been no such thing. ATA has just been 
> gradually enabled. (And initially that resulted in quite a mess because 
> some devices would be supported by two drivers and the kernel couldn't 
> even make up its own mind which one it preferred, resulting in random 
> switches between drivers. At least that was resolved at some point.)
> 
> However, I must admit that Debian has not handled the IDE-ATA switch very 
> well. So far users have mostly been left to deal with any fallout for 
> themselves.

I think that Debian still sticks to IDE (which is correct choice given
goals of this distribution).

> > Please note that no fancy sysfs support was needed to prevent the
> > problem: both stacks (ide & libata) support HDIO_DRIVE_TASK ioctl which
> > can be used to execute commands needed to retrieve/change HPA setting.
> 
> I don't really see how that would help. The fact that fancy ioctls exist 
> does not mean users or even distros have the knowledge needed to use 
> them. IMHO such issues should be dealt with at the level where that 
> knowledge is available: the kernel community.

The coordination from distributions was necessary and the answer from
some distributions was to continuously ignore or downplay the issue.

This has changed only recently with Tejun's work.

> > Moreover the (much needed) work from Tejun doesn't help a tiny bit in
> > case of people migrating their *working* setups from IDE to libata
> 
> From what I've seen now that seems the most important case that needs 
> supporting, as well as the case where a working setup would migrate from 
> IDE with old HPA default to IDE with new HPA default.

There is no IDE with new HPA default at the moment.
--
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/