linux-kernel - Re: [PATCH 0/8] Suspend block api (version 6)

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: <20100503215028.GB18910@srcf.ucam.org>
Date:	Mon, 3 May 2010 22:50:28 +0100
From:	Matthew Garrett <mjg@...hat.com>
To:	Kevin Hilman <khilman@...prootsystems.com>
Cc:	Arve Hjønnevåg <arve@...roid.com>,
	linux-pm@...ts.linux-foundation.org, linux-kernel@...r.kernel.org,
	"Rafael J. Wysocki" <rjw@...k.pl>,
	Alan Stern <stern@...land.harvard.edu>,
	Tejun Heo <tj@...nel.org>, Oleg Nesterov <oleg@...hat.com>,
	Paul Walmsley <paul@...an.com>, magnus.damm@...il.com,
	mark gross <mgross@...ux.intel.com>,
	Arjan van de Ven <arjan@...radead.org>,
	Geoff Smith <geoffx.smith@...el.com>
Subject: Re: [PATCH 0/8] Suspend block api (version 6)

On Mon, May 03, 2010 at 09:40:26AM -0700, Kevin Hilman wrote:

> In my view, the truly significant difference between suspend blockers
> and runtime PM is what happens to userspace.  So far, to me the only
> compelling argument for suspend blockers is the goal of forcibly
> shutting down userspace and thus forcing the system into idle
> (although drivers could still reject a suspend request.)

I'd say that this is certainly the main issue, though the remaining 
periodic timers in the kernel are also inconvenient.

> And if untrusted userspace apps remain as the major problem, maybe we
> should aim for a solution directly targetting that problem.  I'm just
> shooting from the hip now, but maybe containing (cgroups?) untrusted
> processes together into a set that could be frozen/idled so that runtime PM
> would be more effective would be a workable solution?

I considered this. The problem is that not all of your wakeup events 
pass through trusted code. Assume we've used a freezer cgroup and the 
applications are now frozen. One of them is blocking on a network 
socket. A packet arrives and triggers a wakeup of the hardware. How do 
we unfreeze the userspace app?

I agree that the runtime scenario is a far more appealing one from an 
aesthetic standpoint, but so far we don't have a very compelling 
argument for dealing with the starting and stopping of userspace. The 
use-cases that Google have provided are valid and they have an 
implementation that addresses them, and while we're unable to provide an 
alternative that provides the same level of functionality I think we're 
in a poor position to prevent this from going in.

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