linux-kernel - Re: Attempted summary of suspend-blockers LKML thread

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: <20100805133811.GA20565@srcf.ucam.org>
Date:	Thu, 5 Aug 2010 14:38:11 +0100
From:	Matthew Garrett <mjg59@...f.ucam.org>
To:	david@...g.hm
Cc:	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
	Arjan van de Ven <arjan@...radead.org>,
	Arve Hjønnevåg <arve@...roid.com>,
	linux-pm@...ts.linux-foundation.org, linux-kernel@...r.kernel.org,
	pavel@....cz, florian@...kler.org, rjw@...k.pl,
	stern@...land.harvard.edu, swetland@...gle.com,
	peterz@...radead.org, tglx@...utronix.de, alan@...rguk.ukuu.org.uk
Subject: Re: Attempted summary of suspend-blockers LKML thread

On Wed, Aug 04, 2010 at 03:20:04PM -0700, david@...g.hm wrote:

> on the other hand, making an application avoid consuming inappropriate  
> background resources helps everywhere. an explicit "don't let the machine 
> sleep" only works if you are trusted by a system that implements this  
> flag.
>
> yes, it is painful to make the change, but the end result is better (and  
> there are more tools out there to figure things out)

Nobody's denying that it's better, but people are saying they want to 
design a platform that's capable of handling the software we have rather 
than the software we'd like to have.

> but if you have an application in the mid-level trust situation, go ahead 
> and have it talk to a 'keepalive' daemon that is in the 'trusted' set and 
> let the rest of the app run untrusted. As I noted elsewhere, the 
> keepalive daemon would need very little in the way of resources and can 
> implement much more complex policies than anyone is going to be willing 
> to put in the kernel.

That doesn't work. You'll race with wakeup events.

> similar to the current implementation, the arrival of a packet could be  
> counted as activity that keeps the system awake for a bit (your timeout)

How? You're either polling in order to know whether there's network 
activity, or you're having every network packet wake up the policy 
daemon, or you've got something that looks like the kernel side of 
wakelocks.

>> Cell networks typically have no background traffic, for obvious reasons.
>
> but don't most new smartphones also connect up to wifi networks? those 
> are FAR from quiet.

Wifi radio typically dwarfs your other power consumption anyway. The 
typical situation is one where you're not attached to a wifi network.

> I'm not suggesting running all events through some central server (unless 
> you count the kernel as that server),  I'm saying that the decision that  
> the system is idle and therefor can be stopped should be able to take 
> this infomation into account, and if there's a race here, it should be a 
> race that exists everywhere else, so there should be a general solution, 
> not something specific to one use-case. (and definantly not something 
> that requires all software to be modified and trusted to implement)

You're right. It's a race that exists everywhere else, and it's inherent 
unless you have some handshaking between userspace and the kernel when 
entering suspend. Which is what wakelocks provide. Nobody has proposed a 
solution that works without modifying existing code.

-- 
Matthew Garrett | mjg59@...f.ucam.org
--
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/