Bug 216459 - pm-utils - an instant DoS with suspend/hibernate on many machines
pm-utils - an instant DoS with suspend/hibernate on many machines
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: pm-utils (Show other bugs)
6
All Linux
medium Severity medium
: ---
: ---
Assigned To: Phil Knirsch
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-11-20 11:54 EST by Michal Jaegermann
Modified: 2015-03-04 20:17 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-01-23 09:17:43 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Michal Jaegermann 2006-11-20 11:54:19 EST
Description of problem:

There are whole classes of machines where syspend-to-disk, a.k.a
hibernate, may work fine but suspend-to-RAM, a.k.a suspend will
do a suspend part but it will never wake up.  This is the case,
for example, on x86_64 installations where suspend-to-RAM is
currently broken on a kernel level (but, apparently, pretty close
to what should be functioning).  It may be also the situation on
various i386 laptop with a user beeing, to a great extent, on the
mercy of a BIOS.  Possibly also happens that "Suspend" works but
"Hibernate" fails even if I am not aware of examples.

OTOH if gnome-power-manager is installed then one gets on a deskop
both "Suspend" and "Hibernate" buttons and it is easy, by
a mistake or by mischief, hit a "wrong" one.  Closing a laptop lid
may also cause an immediate crash because a default configuration
of actions in gnome-power-manager was incorrect for the given situation
and missed.  It appears that the only way out is to deinstall
gnome-power-manager and loose both.

In truth it is easy to make an offending action "toothless".  It
is enough to add in /etc/pm/config something like:

DISABLE_HIBERNATE="no"
DISABLE_SUSPEND="no"

plus an explanation in a comment, and change pm_main() in 
/etc/pm/functions to have

   if [ "$DISABLE_SUSPEND" != "yes" ] ; then
     pm-pmu --suspend || echo -n "mem" > /sys/power/state
   fi

and

   if [ "$DISABLE_HIBERNATE" != "yes" ] ; then
       echo -n "platform" > /sys/power/disk
       echo -n "disk" > /sys/power/state
   fi

in obvious places.  Then by editing this config file an admin may
prevent nasty results of an incorrect action.  Possibly changes
to pm_main() could be more radical but proposed ones look safe
in a chain of before-and-after events and worked fine in my quick
testing.

A package script may, and really should, edit accordingly that
configuration if we now that "Suspend" for sure will fail like on
x86_64.

Can we also have at least a symlink /etc/sysconfig/power-managment-config,
say, pointing to /etc/pm/config?  At least then it will be in
an expected place too and easier to find.

Version-Release number of selected component (if applicable):
pm-utils-0.19-3
Comment 1 Phil Knirsch 2007-01-23 09:17:43 EST
Both points look really nice. I have them both in the latest development package.

Read ya, Phil

PS: The final idea would be to get to a point where we can use as much info as
we can get about the machine to determine automatically if that machine can
reliably suspend/hibernate (ofc while still being able to "forcefully" enable or
disable it). But thats still some time away...
Comment 2 Michal Jaegermann 2007-01-23 14:04:24 EST
> Both points look really nice.

The situation changed in the meantime a bit in that sense that mine
x86_64 test box is doing a "creditable" suspend and restore.  It takes
a long while before it actually gets into a usable state, despite of
the fact that a picture of a desktop shows up rather quickly, i.e.
with whatever displays actually functioning.  Also a text console
after such experiment is uniformly white but X display seems to be
fine.  Even a console can be restored after a bit of mucking around.
So maybe an automatic switch off for a suspend on x86_64 is
a bit too much?

OTOH with two x86 laptops I have here one is doing suspend to RAM
if 'acpi_sleep=s3_bios noapic' is passed to a kernel and the other
one steadfastly refuses to restore video after a suspend no matter
what. I went through the whole list from http://en.opensuse.org/S2ram
and no dice.  Making sure that suspend is not attempted on this
machine, even by a mistake, is the only sensible option.  "Hibernate"
works there just fine.

Note You need to log in before you can comment on or make changes to this bug.