linux-kernel - Re: Disk spin down issue on shut down/suspend to disk

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>] [day] [month] [year] [list]

Date:	Fri, 10 Aug 2007 20:21:19 -0600
From:	Robert Hancock <hancockr@...w.ca>
To:	trenn@...e.de
Cc:	Pavel Machek <pavel@....cz>, Tejun Heo <htejun@...il.com>,
	Henrique de Moraes Holschuh <hmh@....eng.br>,
	Michael Sedkowski <sedmich@...il.com>,
	"Rafael J. Wysocki" <rjw@...k.pl>, linux-kernel@...r.kernel.org,
	linux-ide@...r.kernel.org, linux-acpi <linux-acpi@...r.kernel.org>,
	firmwarekit-discuss <firmwarekit-discuss@...host.org>
Subject: Re: Disk spin down issue on shut down/suspend to disk

Thomas Renninger wrote:
> On Thu, 2007-08-09 at 15:16 +0000, Pavel Machek wrote:
>> Hi!
>>
>>>> firmwarekit-discuss <firmwarekit-discuss@...host.org> (added to CC list)
>>>> see: http://linuxfirmwarekit.org/
>>>>
>>>> But if I understand this problem right, this won't be easy.
>>>> The ACPI tables are just parsed with system ("iasl ...") and syntactical
>>>> errors/warnings are printed out.
>>>> I also thought about a test, interpreting the DSDT and read out values
>>>> of cpufreq tables and sanity check them. AFAIK the linuxfirmwarekit is
>>>> not designed for that atm. You need to compile in most parts of the
>>>> acpica code and parse and interpret DSDT/SSDT code yourself in the
>>>> firmwarekit core or inside a plugin, then do a walk_namespace call or
>>>> whatever to find the functions/parts you like to examine. This is a lot
>>>> work and needs a proper design (providing an interface to plugins to let
>>>> them easily check specific AML/ASL code).
>>> Furthermore, we don't really know what we're looking for.  How can you
>>> tell a given write to an ioport is issuing STANDBYNOW to an ATA disk or
>>> trying to power the machine off?  Adding to the fun, many modern ATA
>>> controller have more than one way to issue a command.  Maybe we can
>>> match accesses inside regions specified by PCI BARs....  :-(
>> Hmmm... perhaps we should do it the other way. ACPI is allowed to
>> touch the embedded controller, what else? Maybe we should warn as soon
>> as API touches non-EC I/O port?
> 
> This is not working...
> ACPI can and does access all kind of other I/O ports and other
> resources.
> Hmm, are the disk accesses done by ACPI via OperationRegion/Field
> declared variables?
> I try to get a check for those clashing with native drivers (hopefully
> this approach is successful for 2.6.24, can't say for sure yet), I
> wonder whether this one would give a warning like "Libata driver is
> using the same SystemIO/SystemMem resources than ACPI OperationRegion
> declaration XY".
> This would not solve the problem, but at least show the need of such a
> test. Such ACPI vs native driver interference problems are very hard
> nuts (in identifying and solving).
> 
> Can someone post an ASL code snippet how ACPI actually access the disk
> and in which parts/functions, pls.

Again, it's not believed that this is being done via AML, but via a BIOS 
SMM trap on the ACPI sleep state hardware IO port. We have no real 
ability to find out what the BIOS is doing or prevent it in this case.

-- 
Robert Hancock      Saskatoon, SK, Canada
To email, remove "nospam" from hancockr@...pamshaw.ca
Home Page: http://www.roberthancock.com/

-
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/