linux-kernel - Re: RFD: Non-Disruptive Core Dump Infrastructure

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>] [day] [month] [year] [list]
Message-ID: <5227110D.8030100@linux.vnet.ibm.com>
Date:	Wed, 04 Sep 2013 16:23:01 +0530
From:	Janani Venkataraman <jananive@...ux.vnet.ibm.com>
To:	Pavel Emelyanov <xemul@...allels.com>
CC:	linux-kernel@...r.kernel.org,
	Jeremy Fitzhardinge <jeremy.fitzhardinge@...rix.com>,
	Daisuke HATAYAMA <d.hatayama@...fujitsu.com>,
	Andi Kleen <andi@...stfloor.org>,
	Roland McGrath <roland@...k.frob.com>,
	Amerigo Wang <amwang@...hat.com>,
	Christoph Hellwig <hch@....de>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
	Masami Hiramatsu <mhiramat@...hat.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Alexey Dobriyan <adobriyan@...il.com>,
	Oleg Nesterov <oleg@...hat.com>, Tejun Heo <tj@...nel.org>,
	avagin@...nvz.org, gorcunov@...nvz.org,
	James Hogan <james.hogan@...tec.com>,
	Mike Frysinger <vapier@...too.org>,
	"Randy.Dunlap" <rdunlap@...otime.net>,
	Eric Paris <eparis@...hat.com>, ananth@...ibm.com,
	suzuki@...ibm.com, aravinda@...ux.vnet.ibm.com,
	tarundeep.singh@...ibm.com
Subject: Re: RFD: Non-Disruptive Core Dump Infrastructure

On 09/03/2013 04:24 PM, Pavel Emelyanov wrote:
> On 09/03/2013 02:47 PM, Janani Venkataraman wrote:
>> On 09/03/2013 04:01 PM, Pavel Emelyanov wrote:
>>> On 09/03/2013 12:39 PM, Janani Venkataraman wrote:
>>>> Hello,
>>>>
>>>> We are working on an infrastructure to create a system core file of a specific
>>>> process at run-time, non-disruptively. It can also be extended to a case where
>>>> a process is able to take a self-core dump.
>>>
>>> This is very close to what we're trying to do in CRIU. And although image files
>>> containing info about processes are not ELF files, an ability to generate ELF-cores
>>> out of existing CRIU images is one of the features that we were asked for.
>>>
>>>> 2) CRIU Approach :
>>>>
>>>> This makes use of the CRIU tool and checkpoints when a dump is called, collects
>>>> the required details and continues the running process.
>>>> * A self dump cannot be initiated using the command line CRIU which is similar
>>>> to the limitation of gcore.
>>>
>>> This is something we're trying to fix at the moment, as people ask for 'self-dump'
>>> ability as well. We plan to have this implemented in v0.8 (the v0.7 is coming out
>>> today/tomorrow) in about a month.
>>>
>>> I can shed more light on this, if required.
>>>
>>>> * A system call to do the same is being implemented which would help us create
>>>> a self dump.The system call is not upstream yet. We could explore that option as
>>>> well.
>>>
>>> Thanks,
>>> Pavel
>>>
>> Hi,
>>
>> I would like to know more about the "self-dump" ability of CRIU. This is
>> the implementation using system calls if I am not wrong.
>
> Not exactly.
>
> In CRIU project since it's earliest days, we had to heavily patch the kernel
> to make it provide additional APIs for getting more info about running tasks
> and kernel objects. You can find all the patches we've created on the page
> http://criu.org/Commits
>
> For almost all the new APIs we proposed the community asked us to restrict them
> with CAP_SYS_ADMIN checks, so CRIU even for very basic stuff should be run from
> root. The intention was to create the proof-of-concept with maximal and most
> strict protection, and then think harder about less strict checks.
>
> With this the self-dump functionality cannot be implemented as just "CRIU in a
> .so file", since this would only be usable by root processes. So, instead of
> just wrapping the whole CRIU stuff into a library, we use a trickier approach.
> It's described here -- http://criu.org/Self_dump
>
> Briefly -- we will implement the CRIU service, which is a daemon running from
> root and listening on a unix socket. When a task wants to dump himself, it sends
> to the service a "dump me" message. The service then goes and dumps the process.
>
> Thanks,
> Pavel
>

Hi,

What we require for our infrastructure is just a register snapshot and a
memory dump.Do we require CAP_SYS privileges,if we want to dump the only
regset and memory ?

Is it possible to librarize the dump generation routine so that it is
transparent to the user. Also, ideally a single API for dump generation
is preferred for generating the dump, irrespective of whether it is a
self dump or not.

One another aspect we might want to look at is the DoS attacks. Are
there any cases where it is prone to such attacks.

We also looked into the Self-dump page you had mentioned and we would 
like to know more. Is there any additional information/prototype which 
you share with us .Also would it be possible for us to test a few 
patches for the self dump case ?

If converting the dump,to ELF-core format from the existing CRIU Image 
format has not yet been done,we would be happy to contribute towards it.

Thanks,
Janani

--
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/