linux-kernel - Re: Generic events for wake up from S1-S4

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: <20090723191330.GQ28158@elf.ucw.cz>
Date:	Thu, 23 Jul 2009 21:13:30 +0200
From:	Pavel Machek <pavel@....cz>
To:	Henrique de Moraes Holschuh <hmh@....eng.br>
Cc:	"Luis R. Rodriguez" <mcgrof@...il.com>,
	"Rafael J. Wysocki" <rjw@...k.pl>, linux-kernel@...r.kernel.org,
	Johannes Berg <johannes@...solutions.net>,
	"John W. Linville" <linville@...driver.com>,
	Jouni Malinen <j@...fi>,
	linux-wireless <linux-wireless@...r.kernel.org>,
	Stephen Chen <Stephen.Chen@...eros.com>
Subject: Re: Generic events for wake up from S1-S4

On Thu 2009-07-23 15:57:20, Henrique de Moraes Holschuh wrote:
> On Thu, 23 Jul 2009, Pavel Machek wrote:
> > On Sat 2009-07-18 20:56:10, Henrique de Moraes Holschuh wrote:
> > > On Sat, 18 Jul 2009, Luis R. Rodriguez wrote:
> > > > Hm yeah, but I doubt someone will do that, generally we'd get one wake
> > > > up event. Can't we just report the first one and ignore the rest?
> > > 
> > > Well, I'd say keeping it simple is best, here.  What if you ignore the more
> > > interesting wakeup events by chance (and it is really up to userspace to
> > > know what it considers interesting...)?  IMHO, just issue as many
> > > notifications as needed, let userspace filter it if it wants.
> > > 
> > > But if you guys are talking about something really generic, shouldn't it
> > > also provide the important "why" along with the "who"?
> > > 
> > > Even for the most common cases, the "why" is useful: userspace may well want
> > > to run special routines when it wakes up because of WoL and WoW (instead of
> > > a key press, lid open or mouse movement...).
> > 
> > What special routines?
> 
> Starting a remote maintenance shell is a common usage scenario on corporate
> environments.

But... You want to start maintenance shell not on wakeup from WoL, but
on receiving the magic packet. If you hit the keyboard before to wake
up the machine, and the magic packet still comes, you still want the
remote maintenance shell.

> Besides, it is a generic wakeup notification we're talking about, isn't it?
> I have some that have nothing to do with WoW or WoL:
> 
> 1. Thermal alarm
> 2. Battery alarm
> 3. Hotunplug request (bay/dock): umount stuff, cleanly undock, then go back
> to sleep (optional)

Well, battery&thermal alarms would certainly be useful. (And yes, I
believe it is a bug in ACPI that we don't printk on battery critical).

> > Note that the "why" is unreliable by design. Network driver will
> > ignore WoL during run-time, right?
> 
> "Why" is unrealible?  I don't follow your reasoning.  It should be as
> reliable as "who"...

See above. The wakeup events race with each other.

> If the WoW/WoL device doesn't know why it woke up the system, it uses the
> generic reason for network devices (I don't even know if a network device
> has more than one reason for wakeup).  If a different device wakes the
> system, it might know why and provide that reason.  And if it doesn't know
> it woke up the system, it sends no notification at all.

See above.

									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/