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: <E62404B31D39064FBDD0B843ADF05A7D2D395FC7AA@SC-VEXCH4.marvell.com>
Date:	Tue, 18 Sep 2012 23:26:41 -0700
From:	Feng Hong <hongfeng@...vell.com>
To:	"Eric W. Biederman" <ebiederm@...ssion.com>
CC:	"akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
	"gorcunov@...nvz.org" <gorcunov@...nvz.org>,
	"keescook@...omium.org" <keescook@...omium.org>,
	"serge.hallyn@...onical.com" <serge.hallyn@...onical.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH] poweroff: fix bug in orderly_poweroff

Hi, Eric,

I agree with your idea, I'll prepare another patch, thanks for remind this possible issue.

--
Best Regards,
Feng Hong
Application Processor Software Engnieer 
Marvell Technology (Shanghai) Ltd


-----Original Message-----
From: Eric W. Biederman [mailto:ebiederm@...ssion.com] 
Sent: 2012年9月19日 13:58
To: Feng Hong
Cc: akpm@...ux-foundation.org; gorcunov@...nvz.org; keescook@...omium.org; serge.hallyn@...onical.com; linux-kernel@...r.kernel.org
Subject: Re: [PATCH] poweroff: fix bug in orderly_poweroff

Feng Hong <hongfeng@...vell.com> writes:

> Hi, Eric
>
> 1. We are developing on an Android phone platform, we use thermal
> framework to monitor the temperature, when the temperature above like
> 110 degree, thermal framework will use orderly_shutdown to shutdown
> phone, however, on Android platform there is no " /sbin/poweroff " cmd
> ready . Then we want "fail ret" to trigger force shutdown (use
> kernel_power_off), but always we get "suc ret"

> 2. Here the caller just wait for "poweroff" userspace application, if
> it block the called, then it's the "poweroff" problem itself

> 3. As in the original orderly_shutdown design, we must get the right
> "ret", if this ret is always "0", then it obey orderly_poweroff design
> goal. Step 2: force shutdown is always useless code. 

That sounds like a clear case that we need to change it to
UMH_WAIT_EXEC.

Changing it to UMH_WAIT_PROC seems much more dangerous.

Eric

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ