From: Pavel Emelyanov <xemul@parallels.com>
To: Janani Venkataraman1 <jananive@in.ibm.com>
Cc: <adobriyan@gmail.com>, <akpm@linux-foundation.org>,
<amwang@redhat.com>, <ananth@linux.vnet.ibm.com>,
<andi@firstfloor.org>, <aravinda@linux.vnet.ibm.com>,
<avagin@openvz.org>, <d.hatayama@jp.fujitsu.com>,
<eparis@redhat.com>, <gorcunov@openvz.org>, <hch@lst.de>,
<james.hogan@imgtec.com>, <jeremy.fitzhardinge@citrix.com>,
<kosaki.motohiro@jp.fujitsu.com>, <linux-kernel@vger.kernel.org>,
<mhiramat@redhat.com>, <oleg@redhat.com>, <rdunlap@xenotime.net>,
<roland@hack.frob.com>, <suzuki@linux.vnet.ibm.com>,
<tarundsk@linux.vnet.ibm.com>, <tj@kernel.org>,
<torvalds@linux-foundation.org>, <vapier@gentoo.org>
Subject: Re: [RFC] [PATCH 00/19] Non disruptive application core dump infrastructure using task_work_add()
Date: Wed, 9 Oct 2013 12:57:51 +0400 [thread overview]
Message-ID: <52551A8F.5080904@parallels.com> (raw)
In-Reply-To: <OFE96703A1.612D0E95-ON65257BFE.00379B31-65257BFE.0037FF3B@in.ibm.com>
On 10/08/2013 02:12 PM, Janani Venkataraman1 wrote:
>
>
>
>
> From: Pavel Emelyanov <xemul@parallels.com>
> To: Janani Venkataraman1/India/IBM@IBMIN,
> Cc: <linux-kernel@vger.kernel.org>, <amwang@redhat.com>,
> <rdunlap@xenotime.net>, <andi@firstfloor.org>,
> <aravinda@linux.vnet.ibm.com>, <hch@lst.de>,
> <mhiramat@redhat.com>, <jeremy.fitzhardinge@citrix.com>,
> <suzuki@linux.vnet.ibm.com>, <kosaki.motohiro@jp.fujitsu.com>,
> <adobriyan@gmail.com>, <tarundsk@linux.vnet.ibm.com>,
> <vapier@gentoo.org>, <roland@hack.frob.com>, <tj@kernel.org>,
> <ananth@linux.vnet.ibm.com>, <gorcunov@openvz.org>,
> <avagin@openvz.org>, <oleg@redhat.com>, <eparis@redhat.com>,
> <d.hatayama@jp.fujitsu.com>, <james.hogan@imgtec.com>,
> <akpm@linux-foundation.org>, <torvalds@linux-foundation.org>
> Date: 10/04/2013 04:08 PM
> Subject: Re: [RFC] [PATCH 00/19] Non disruptive application core dump
> infrastructure using task_work_add()
>
>
>
> On 10/04/2013 02:30 PM, Janani Venkataraman wrote:
>> Hi all,
>>
>
>> This series is based on the Task work add approach. We didn't adopt the
> CRIU
>> approch because of the following reasons:
>>
>> * It is not upstream yet.
>
> It is, starting from criu-v0.7 + linux-3.11
>
>> * There are concerns about the security of the dump.
>
> Can you elaborate on this? Is it fixable in CRIU at all?
>
>> * It involves a lot of changes and this approach provides a UNIX style
>> interface.
>
> Can you also shed more light on this -- what changes do you mean?
>
> We had a prototype ready earlier using the freezer approach.
> http://lwn.net/Articles/419756/
>
> We made a couple of minor changes to it and implemented using task work
> add.
> We wanted to know what the community felt about this approach.
>
> Also in the previous RFD, Andi Kleen had mentioned a concern on the
> security with
> respect to the daemon approach for a self dump in CRIU.
We have this thing addressed -- when one requests a self-dump from criu daemon
the latter
a) gets pid to dump from SO_PEERCRED, thus requester cannot just send some other's pid
b) doesn't dump tasks that belong to user other than the one who requested the dump
What other security concerns do you have? We're also interested in addressing them.
> Thanks.
> Janani
>
> .
>
next prev parent reply other threads:[~2013-10-09 8:58 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-04 10:30 [RFC] [PATCH 00/19] Non disruptive application core dump infrastructure using task_work_add() Janani Venkataraman
2013-10-04 10:30 ` [PATCH 01/19] Create elfcore-common.c for ELF class independent core generation helpers Janani Venkataraman
2013-10-04 10:30 ` [PATCH 02/19] Make vma_dump_size() generic Janani Venkataraman
2013-10-08 0:23 ` Ryan Mallon
2013-10-08 3:52 ` Janani Venkataraman1
2013-10-04 10:31 ` [PATCH 03/19] Make fill_psinfo generic Janani Venkataraman
2013-10-04 10:31 ` [PATCH 04/19] Rename compat versions of the reusable core generation routines Janani Venkataraman
2013-10-04 10:31 ` [PATCH 05/19] Export the reusable ELF " Janani Venkataraman
2013-10-04 10:31 ` [PATCH 06/19] Define API for reading arch specif Program Headers for Core Janani Venkataraman
2013-10-04 10:31 ` [PATCH 07/19] ia64 impelementation for elf_core_copy_extra_phdrs() Janani Venkataraman
2013-10-04 10:31 ` [PATCH 08/19] elf_core_copy_extra_phdrs() for UML Janani Venkataraman
2013-10-04 10:31 ` [PATCH 09/19] Create /proc/pid/core entry Janani Venkataraman
2013-10-04 10:31 ` [PATCH 10/19] Track the core generation requests Janani Venkataraman
2013-10-04 10:31 ` [PATCH 11/19] Check if the process is an ELF executable Janani Venkataraman
2013-10-04 10:32 ` [PATCH 12/19] Hold the threads using task_work_add Janani Venkataraman
2013-10-04 10:32 ` [PATCH 13/19] Create ELF Header Janani Venkataraman
2013-10-04 10:32 ` [PATCH 14/19] Create ELF Core notes Data Janani Venkataraman
2013-10-04 10:32 ` [PATCH 15/19] Calculate the size of the core file Janani Venkataraman
2013-10-04 10:32 ` [PATCH 16/19] Generate the data sections for ELF Core Janani Venkataraman
2013-10-04 10:32 ` [PATCH 17/19] Identify the ELF class of the process Janani Venkataraman
2013-10-04 10:33 ` [PATCH 18/19] Adding support for compat ELF class data structures Janani Venkataraman
2013-10-04 10:33 ` [PATCH 19/19] Compat ELF class core generation support Janani Venkataraman
2013-10-04 10:38 ` [RFC] [PATCH 00/19] Non disruptive application core dump infrastructure using task_work_add() Pavel Emelyanov
2013-10-07 18:57 ` Tejun Heo
2013-10-08 10:14 ` Janani Venkataraman1
2013-10-08 10:12 ` Janani Venkataraman1
2013-10-09 8:57 ` Pavel Emelyanov [this message]
2013-10-04 13:44 ` Andi Kleen
2013-10-07 6:07 ` Suzuki K. Poulose
2013-10-07 13:58 ` Oleg Nesterov
2013-10-07 18:10 ` Andi Kleen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=52551A8F.5080904@parallels.com \
--to=xemul@parallels.com \
--cc=adobriyan@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=amwang@redhat.com \
--cc=ananth@linux.vnet.ibm.com \
--cc=andi@firstfloor.org \
--cc=aravinda@linux.vnet.ibm.com \
--cc=avagin@openvz.org \
--cc=d.hatayama@jp.fujitsu.com \
--cc=eparis@redhat.com \
--cc=gorcunov@openvz.org \
--cc=hch@lst.de \
--cc=james.hogan@imgtec.com \
--cc=jananive@in.ibm.com \
--cc=jeremy.fitzhardinge@citrix.com \
--cc=kosaki.motohiro@jp.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mhiramat@redhat.com \
--cc=oleg@redhat.com \
--cc=rdunlap@xenotime.net \
--cc=roland@hack.frob.com \
--cc=suzuki@linux.vnet.ibm.com \
--cc=tarundsk@linux.vnet.ibm.com \
--cc=tj@kernel.org \
--cc=torvalds@linux-foundation.org \
--cc=vapier@gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.