linux-kernel - Re: [linux-pm] [PATCH 1/8] PM: Add suspend block api.

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

Message-ID: <20100524185735.GC1292@ucw.cz>
Date:	Mon, 24 May 2010 20:57:35 +0200
From:	Pavel Machek <pavel@....cz>
To:	Arve Hj?nnev?g <arve@...roid.com>
Cc:	James Kosin <james.kosin.04@....edu>, linux-kernel@...r.kernel.org
Subject: Re: [linux-pm] [PATCH 1/8] PM: Add suspend block api.

Hi!

> >>> Tony,
> >>> Wouldn't this be handled by the idle task, or task manager?
> >>>
> >>> When all tasks are suspended and not doing anything that should be the
> >>> first clue that a real suspend cycle could be attempted.
> >>>
> >>>
> >> One if the benefit we get from using suspend is that an unprivileged
> >> app that does not have access to suspend blockers cannot prevent
> >> suspend. You lose this advantage if you trigger suspend only from the
> >> idle task.
> >>
> >>
> > If the process (privileged or unprivileged) doesn't want to suspend, why
> > not just provide an interface to allow suspend to be turned off at the
> > user level.  This could block the suspend cycle in itself, and you
> > shouldn't need fine grained off/on cycles.  If an application really
> > needs the system not to suspend then they (the user) should know the
> > consequences and power requirements for such a task.
> >
> > I didn't say it had to be only from the idle task; but, that is the most
> > logical place.  If the other threads are not idle then they really
> > require work and will most likely already have a bock on the suspend anyway.

> I think you missed my point. Unprivileged processes should not be
> allowed to prevent suspend.

Currently, we do not suspend automatically, and not suspending when
*anything* is running is clearly backwards compatible....

 If suspend is disallowed, application doing while(1); will consume
more power than the one doing sleep(1) so.... I'm not sure how much
sense such "security policy" makes.

Anyway, for android use case, maybe you could have something like
ksuspendd, and adjust its priority? That way, you could have tasks
below the priority of ksuspendd, and those would not block suspend.

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