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: <CALCETrUcq880-FPWapHAJbF5J+VC21KBeDjOLRVo0KZ9pH6f5Q@mail.gmail.com>
Date:	Thu, 12 Mar 2015 11:25:43 -0700
From:	Andy Lutomirski <luto@...capital.net>
To:	Pedro Alves <palves@...hat.com>
Cc:	Oleg Nesterov <oleg@...hat.com>,
	Jan Kratochvil <jan.kratochvil@...hat.com>,
	Sergio Durigan Junior <sergiodj@...hat.com>,
	GDB Patches <gdb-patches@...rceware.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: vvar, gup && coredump

On Thu, Mar 12, 2015 at 11:19 AM, Pedro Alves <palves@...hat.com> wrote:
> On 03/12/2015 05:46 PM, Oleg Nesterov wrote:
>> On 03/12, Oleg Nesterov wrote:
>>>
>>> Yes, this is true. OK, lets not dump it.
>>
>> OTOH. We can probably add ->access() into special_mapping_vmops, this
>> way __access_remote_vm() could work even if gup() fails ?
>>
>> Jan, Sergio. How much do we want do dump this area ? The change above
>> should be justified.
>
> Memory mappings that weren't touched since they were initially mapped can
> be retrieved from the program binary and the shared libraries, even if
> the core dump is moved to another machine.  However, in vvar case,
> sounds like  there's nowhere to read it from offline?  In that case,
> it could be justified to dump it.

This is why we currently dump the vdso text.  On arm64 (the only other
architecture that uses a real vma for vvar data IIRC), we use a more
normal vma and we dump it.  x86 is the odd one out here.

We could just leave the kernel alone.  The data that gets dumped is of
dubious value, but it could be slightly helpful when debugging vdso
crashes*, but, of course, dumping it is inherently racy.


* The vdso never crashes :)

--Andy

>
> Thanks,
> Pedro Alves
>



-- 
Andy Lutomirski
AMA Capital Management, LLC
--
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