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: <20061128120916.GG2352@gamma.logic.tuwien.ac.at>
Date:	Tue, 28 Nov 2006 13:09:16 +0100
From:	Andreas Leitgeb <avl@...ic.at>
To:	Tejun Heo <htejun@...il.com>
Cc:	avl@...ic.at, Alan <alan@...rguk.ukuu.org.uk>,
	linux-kernel@...r.kernel.org
Subject: Re: Allow turning off hpa-checking.

It seems I was too eagerly deleting context from my mails.
This made people misunderstand my questions or answer
details that have been clarified in previous mails already.

I did learn quite a lot already about harddisks during this thread.
"Thank you" to Alan.  In particular, about the quantities involved:

                         1                      2
+---------------------------------------------+---+
                                   ^-3
There is
   1) the "native" size of the disk: strictly constant
   2) the spare sectors for remapping bad ones. (not included in 1)
   3) An arbitrary quantity, being what the drive advertises as size.

Bios thinks 3) is the disks total size. So does Linux before the
hpa-check.  During that "hpa-check", Linux queries the quantity "1)",
which is indeed the disks (constant) size. 

There seem to be many (in some way conflicting) uses for "3)":
  - fool the BIOS: because bioses might get upset for too large disks.
  - fool some old OS: because the OS might get upset ---"---
  - reserve some sectors for some non-volatile data hidden to 
      certain systems e.g. for "nanny the user"-purposes.

This thread is (for one part) about another appearant use of "3)",
namely by the drive to tell that "2)" is exhausted, and less than
"1)" sectors are left usable.  So quantity "3)" is set to the number
of actually physically remaining sectors.

This theory is backed by my observation of a nearly-broken disk,
that the quantity "3)" gradually goes down one step after some time.
The first such step was, when I noticed the problem about half a
year ago, and just recently it stepped down by another one.

Linux queries the real size "1)", gets read errors on the last two
sectors and consequencially turns off dma making the machine awfully
slow.  But this is not a kernel's problem, because really the disk
should be replaced (it doesn't contain precious data, so I keep
watching its degrade, till it no longer does anything).

The point I'm really trying to make is, that there should be a
boot option, to disable the query for "1)".  This *must* be a
boot option, because the querying that I want to be able to
prevent happens at boot time.
My broken drive surely doesn't justify the option (or even this
thread), but the third one of the "uses for 3)" mentioned above
does. Once the native size is read, I no longer know how many
sectors were previously "hidden away" by HPA, except by checking
the kernel-log.

While Alan has already said, why he thought that this was the
wrong approach, the reasoning was based on a misunderstanding
of my question, which I here tried to clear up.

-
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