linux-kernel - Re: [Patch BUGFIX] kcore: fix its wrong size on x86

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]

Date:	Tue, 16 Jun 2009 12:27:36 -0700
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Américo Wang <xiyou.wangcong@...il.com>
Cc:	Tao Ma <tao.ma@...cle.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org, Alexey Dobriyan <adobriyan@...il.com>
Subject: Re: [Patch BUGFIX] kcore: fix its wrong size on x86_64

Américo Wang <xiyou.wangcong@...il.com> writes:

> On Mon, Jun 15, 2009 at 6:08 PM, Eric W. Biederman<ebiederm@...ssion.com> wrote:
>> Amerigo Wang <xiyou.wangcong@...il.com> writes:
>>
>>> Fix wrong /proc/kcore size on x86_64.
>>>
>>> x86_64 uses __va() macro to caculate the virtual address passed to kclist_add()
>>> but decodes it with its own macro kc_vadd_to_offset(). This is wrong.
>>
>> Ok.  I finally understand what is going on here, and no kc_vaddr_to_offset
>> is not wrong when applied to a virtual address.  In fact I expect the current
>> definition makes things a bit more predictable.
>>
>> And yes kclist_add is must be given a virtual address
>>
>>> Also, according to Documentation/x86/x86_64/mm.txt, kc_vaddr_to_offset()
>>> is wrong too.
>>
>> How so?  The file offset is a number space that is different from both
>> physical and virtual addresses.
>
> Why? They _do_ have some calculated relations.

Sure.  The offset is what you give to read/write.  The virtual
addresses are what the kernel uses.  In general in a core file they
are only tied together with the elf header.   We do something a little
more pragmatic in the kernel.

>>> So just remove them, use the generic macro.
>>
>> I think a case can be made either way.  In practice neither answer
>> gives us a dense offset space on x86_64 so I think I prefer the
>> current definition which sets or clears the high bits as opposed
>> to something that mangles the address more.
>>
>
> I am trying to dig more... There must be something wrong there.

How so?

>> It uses get_kcore_size and (size_t)high_memory - PAGE_OFFSET + PAGE_SIZE;
>> The second definition being bogus as it has nothing to do with which
>> offsets are accepted.
>
> Agreed. Maybe we can just remove the second one and update the doc?

Yes.  It isn't critical but reducing confusion is good.
Do you want to cook up the patch for that?

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