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:	Mon, 15 Jun 2009 13:59:08 +0800
From:	Tao Ma <tao.ma@...cle.com>
To:	Amerigo Wang <xiyou.wangcong@...il.com>
CC:	"Eric W. Biederman" <ebiederm@...ssion.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

Hi Amerigo,
	Just patched my kernel and tested.
	The bad news is that although the number is changed, but it isn't right 
either.

Here is the output.
[root@...t3 ~]# ls -l /proc/kcore
-r-------- 1 root root 131941393240064 Jun 15 13:39 /proc/kcore

But your patch does change something. I just try your commands in 
another box which show the right value after reboot. And the result is:

[root@...t8 ~]# ls -l /proc/kcore
-r-------- 1 root root 5301604352 Jun 15 13:35 /proc/kcore
[root@...t8 ~]# readelf -l /proc/kcore

Elf file type is CORE (Core file)
Entry point 0x0
There are 6 program headers, starting at offset 64

Program Headers:
   Type           Offset             VirtAddr           PhysAddr
                  FileSiz            MemSiz              Flags  Align
   NOTE           0x0000000000000190 0x0000000000000000 0x0000000000000000
                  0x00000000000008bc 0x0000000000000000         0
   LOAD           0x000077ffff601000 0xffffffffff600000 0x0000000000000000
                  0x0000000000800000 0x0000000000800000  RWE    1000
   LOAD           0x000077ffa0001000 0xffffffffa0000000 0x0000000000000000
                  0x000000005f000000 0x000000005f000000  RWE    1000
   LOAD           0x000077ff8200a000 0xffffffff82009000 0x0000000000000000
                  0x00000000006ceb50 0x00000000006ceb50  RWE    1000
   LOAD           0x00003a0000001000 0xffffc20000000000 0x0000000000000000
                  0x00001fffffffffff 0x00001fffffffffff  RWE    1000
   LOAD           0x0000000000001000 0xffff880000000000 0x0000000000000000
                  0x000000013c000000 0x000000013c000000  RWE    1000
[root@...t8 ~]# ls -l /proc/kcore
-r-------- 1 root root 131941393240064 Jun 15 13:35 /proc/kcore

So you see, the second "ls -l" will show the wrong value.

Regards,
Tao

Amerigo Wang wrote:
> On Fri, Jun 12, 2009 at 09:20:50PM -0700, Eric W. Biederman wrote:
>> Amerigo Wang <xiyou.wangcong@...il.com> writes:
>>
>>> Fix wrong /proc/kcore size on x86_64.
>> How does that change anything?
> 
> Please check the description below.
> 
>>> 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.
>>>
>>> Also, according to Documentation/x86/x86_64/mm.txt, kc_vaddr_to_offset()
>>> is wrong too.
>>>
>>> So just remove them, use the generic macro.
>>>
>>> BTW, the man page for /proc/kcore is wrong, its size can be more than
>>> the physical memory size, because it also contains memory area of
>>> vmalloc(), vsyscall etc...
>> The set of offsets that are usable sure.
> 
> We have generic kc_vaddr_to_offset() etc. in fs/proc/kcore.c.
> 
> 
>> However the size from stat is:
>>          proc_root_kcore->size = (size_t)high_memory - PAGE_OFFSET + PAGE_SIZE;
>>
>> Which can not be different than the physical memory size.
> 
> I never say this is not different, of course they are same, but what Tao
> reported is the wrong size after a read operation, please try the following:
> 
> #ls -l /proc/kcore
> #readelf -l /proc/kcore
> #ls -l /proc/kcore
> 
> You will find the *second* 'ls -l /proc/kcore' reports a size much more
> than the physical mem size.
> 
> And you will notice the difference of it after this patch applied.
> 
> 
--
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