linux-kernel - Re: [PATCH 3/4] coredump: ELF-FDPIC: enable to omit anonymous shared memory

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: <45DD2B15.1030605@hitachi.com>
Date:	Thu, 22 Feb 2007 14:33:09 +0900
From:	"Kawai, Hidehiro" <hidehiro.kawai.ez@...achi.com>
To:	Robin Holt <holt@....com>, David Howells <dhowells@...hat.com>
Cc:	Andrew Morton <akpm@...l.org>,
	kernel list <linux-kernel@...r.kernel.org>,
	Pavel Machek <pavel@....cz>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>,
	sugita <yumiko.sugita.yf@...achi.com>,
	Satoshi OSHIMA <soshima@...hat.com>,
	"Hideo AOKI@...hat" <haoki@...hat.com>
Subject: Re: [PATCH 3/4] coredump: ELF-FDPIC: enable to omit anonymous shared
    memory

Hi David and Robin,

Thank you for your reply.

Robin Holt wrote:
> On Wed, Feb 21, 2007 at 11:33:31AM +0000, David Howells wrote:
> 
>>Kawai, Hidehiro <hidehiro.kawai.ez@...achi.com> wrote:
>>
>>>Is coredump_setting_sem a global semaphore?  If so, it prevents concurrent
>>>core dumping.
>>
>>No, it doesn't.  Look again:
>>
>>	int do_coredump(long signr, int exit_code, struct pt_regs * regs)
>>	{
>>		<setup vars>
>>
>> >>>>		down_read(&coredump_settings_sem);

Oh, I'm sorry.  I have overlooked it.  There is no problem.


>>>Additionally, while some process is dumped, writing to
>>>coredump_omit_anon_shared of unrelated process will be blocked.
>>
>>Yes, but that's probably reasonable.  How likely (a) is a process to coredump,
>>and (b) is a coredump to occur simultaneously with someone altering their
>>settings?
> 
> And (c) altering the setting during a core dump going to produce an
> unusable core dump.  I don't think the locking is that difficult to add
> and it just makes sense.  I would venture a guess that it will take less
> time to actually do the locking than to continue arguing it is not needed
> when it clearly appears it is needed for even a small number of cases.

Okay, the probability that the process is blocked in the proc handler seems
to be small.  But I'm not sure if problems never occur in enterprise use.
So I'd like to use down_write_trylock() as Robin said before. And if it
fails to acquire the lock, it returns EBUSY immediately.
Do you have any comments?

Thanks,
-- 
Hidehiro Kawai
Hitachi, Ltd., Systems Development Laboratory

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