linux-kernel - Re: [RFC PATCH] freezer: allow killing of frozen tasks

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: <CAMbhsRT-a-TMr369Poo5OMyw=TMrQxpTfk-1zDFKp0YYWv7xLg@mail.gmail.com>
Date:	Wed, 25 Sep 2013 18:46:44 -0700
From:	Colin Cross <ccross@...roid.com>
To:	"Rafael J. Wysocki" <rjw@...k.pl>
Cc:	Kyungmin Park <kmpark@...radead.org>, Tejun Heo <tj@...nel.org>,
	Bartlomiej Zolnierkiewicz <b.zolnierkie@...sung.com>,
	Pavel Machek <pavel@....cz>,
	Linux PM list <linux-pm@...r.kernel.org>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [RFC PATCH] freezer: allow killing of frozen tasks

On Wed, Sep 25, 2013 at 1:07 AM, Rafael J. Wysocki <rjw@...k.pl> wrote:
> On Wednesday, September 25, 2013 02:52:26 PM Kyungmin Park wrote:
>> On Tue, Aug 20, 2013 at 9:41 PM, Rafael J. Wysocki <rjw@...k.pl> wrote:
>> > On Tuesday, August 20, 2013 08:27:27 AM Tejun Heo wrote:
>> >> On Tue, Aug 20, 2013 at 02:34:14PM +0200, Rafael J. Wysocki wrote:
>> >> > On Tuesday, August 20, 2013 08:22:00 AM Tejun Heo wrote:
>> >> > > On Tue, Aug 20, 2013 at 02:30:18PM +0200, Rafael J. Wysocki wrote:
>> >> > > > > So, I don't think we can simply turn TASK_UNITERRUPTIBLE to
>> >> > > > > TASK_KILLABLE at this point.  We really need to strictly define where
>> >> > > > > a task can freeze before being able to do anything like this.
>> >> > > >
>> >> > > > But we could do that for user space tasks I suppose?
>> >> > >
>> >> > > Even for userland tasks, we don't know where the task is stuck at.  I
>> >> > > think there are enough freeze points in the kernel which are in the
>> >> > > middle of something which can be used by userland tasks excuting some
>> >> > > syscall.  We need to collect all those sites into well defined trap
>> >> > > points before doing this.
>> >> >
>> >> > OK, thanks!
>> >>
>> >> I scanned through try_to_freeze() users and it seems like we don't
>> >> have that many which can be hit by userland tasks.  I think it should
>> >> be doable to audit all the users, remove the ones which can be invoked
>> >> by userland and make try_to_freeze() whine loudly if it's running off
>> >> a userland task except from well-defined spots.
>> >
>> > Which might be worth doing anyway to be sure we know what's going on.
>> >
>> >> Anyways, we need to ensure that userland task doesn't get stuck deep in the
>> >> kernel before allowing this.
>> >
>> > Agreed.
>>
>> Are there any update? we need this feature to kill frozen app easily.
>> Don't need to thaw app to kill.
>
> No updates, but the above pretty much describes what needs to be done.

FWIW, the places I added try_to_freeze (which are all accessible from
userspace tasks) were all audited to make sure they weren't holding
any shared resources.  I didn't check if they would leak any memory if
the process was killed there, but they aren't holding any locks.  It's
pretty easy to audit them, just follow the error paths up each
function - if the first error path after the freezing function doesn't
free any resources then that function is safe, and repeat for each
function that calls it.

On the other hand, would it be better to send a kill to the process
and thaw it, and let it exit before returning to userspace?
--
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/