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

Message-ID: <20070809151610.GD3926@ucw.cz>
Date:	Thu, 9 Aug 2007 15:16:10 +0000
From:	Pavel Machek <pavel@....cz>
To:	Tejun Heo <htejun@...il.com>
Cc:	trenn@...e.de, 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

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?
							Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-
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/