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: <20160128132447.6b8bec2c@lxorguk.ukuu.org.uk>
Date:	Thu, 28 Jan 2016 13:24:47 +0000
From:	One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>
To:	Keerthy <j-keerthy@...com>
Cc:	<linux-kernel@...r.kernel.org>, <oleg@...hat.com>,
	<toshi.kani@...com>, <linux-omap@...r.kernel.org>,
	<linux-pm@...r.kernel.org>, <linux-patch-review@...t.ti.com>,
	<nm@...com>, <grygorii.strashko@...com>, <mingo@...nel.org>,
	<josh@...htriplett.org>, <rui.zhang@...el.com>,
	<edubezval@...il.com>
Subject: Re: [PATCH 0/2] reboot: Introduce emergency_poweroff function

On Thu, 28 Jan 2016 18:36:27 +0530
Keerthy <j-keerthy@...com> wrote:

> The series introduces a new function emergency_poweroff which shuts
> down the system after a configurable period of time. emergency_poweroff
> is appropriate in case of thermal shutdown scenario.

That depends upon the system. 

If your hardware has its own built in thermal reset protection then it
will merely make things worse by causing unneeded crashes.

If your device doesn't have protection then you have bigger problems
because a kernel crash or spin in interrupt space could easily mean that
the thermal thermals but doesn't ever run any delayed work. On those that
have a watchdog as well it should be using the hardware watchdog for
protection not relying upon schedule_delayed_work to get work done.

So IMHO this should get a resounding NAK as it stands. For most systems
it's a backward change, for most of those that need more protection it
doesn't look the right answer.

In particular if you need to be sure the box goes off *right now* you
don't want to schedule work because there are so many ways that it might
never execute the work when the box is failing.

Do your devices actually *really* need this, are you saying that someone
who roots the device can disable this code and physically destroy the
product ? If they do then I'd much rather see thermal_core call
thermal_poweroff(), and define that on a platform basis - so for x86 it
would be orderly_poweroff(), for your platform it might well be a
function that right that instant bangs the registers to force power off,
devices with watchdogs might write the watchdog with a 5 second timer and
then try and do an orderly_poweroff and so forth.

Alan

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ