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: <45B59218.4040201@hitachi.com>
Date:	Tue, 23 Jan 2007 13:42:00 +0900
From:	"Kawai, Hidehiro" <hidehiro.kawai.ez@...achi.com>
To:	Pavel Machek <pavel@....cz>
Cc:	Andrew Morton <akpm@...l.org>, linux-kernel@...r.kernel.org,
	gregkh@...e.de, james.bottomley@...eleye.com,
	Satoshi OSHIMA <soshima@...hat.com>,
	"Hideo AOKI@...hat" <haoki@...hat.com>,
	sugita <yumiko.sugita.yf@...achi.com>,
	Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>,
	Alan Cox <alan@...rguk.ukuu.org.uk>
Subject: Re: [PATCH] binfmt_elf: core dump masking support

Hi,

>>>(run echo 1 > coremask, echo 0 > coremask in a loop while dumping
>>>core. Do you have enough locking to make it work as expected?)
>>
>>Currently, any lock isn't acquired.  But I think the kernel only
>>have to preserve the coremask setting in a local variable at the
>>begining of core dumping.  I'm going to do this in the next version.
> 
> No, I do not think that is enough. At minimum, you'd need atomic_t
> variable. But I'd recomend against it. Playing with locking is tricky.

Why do you think it is not enough?  I think that any locking is not
needed.
My design principle is that the core dump routine is controlled by
the bitmask which was assigned to the dumping process at the time of
starting core dump. So if a coremask setting is changed while
core dumping, the change doesn't affect current dumping process.
This can be implemented as follows:

   core_dump_start:
  unsigned int mask = current->mm->coremask;
  for each VMA {
    write a header which depends on the result of maydump(vma, mask)
  }
  for each VMA {
    write a body which depends on the result of maydump(vma, mask)
  }

NOTE:
  maydump() is the central function, which decides whether a given
  VMA should be dumped or not.

What do you think about this?


Best regards,
-- 
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ