linux-kernel - Re: [PATCH] proc: do not show VmExe bigger than total executable virtual 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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <8e7872bf-5af2-91db-f35e-921990849dda@suse.cz>
Date:   Fri, 1 Dec 2017 18:25:25 +0100
From:   Vlastimil Babka <vbabka@...e.cz>
To:     Konstantin Khlebnikov <khlebnikov@...dex-team.ru>,
        Andrew Morton <akpm@...ux-foundation.org>
Cc:     linux-mm@...ck.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] proc: do not show VmExe bigger than total executable
 virtual memory

On 10/11/2017 09:00 AM, Konstantin Khlebnikov wrote:
> On 11.10.2017 01:25, Andrew Morton wrote:
>> On Fri, 06 Oct 2017 14:32:34 +0300 Konstantin Khlebnikov <khlebnikov@...dex-team.ru> wrote:
>>
>>> If start_code / end_code pointers are screwed then "VmExe" could be bigger
>>> than total executable virtual memory and "VmLib" becomes negative:
>>>
>>> VmExe:	  294320 kB
>>> VmLib:	18446744073709327564 kB
>>>
>>> VmExe and VmLib documented as text segment and shared library code size.
>>>
>>> Now their sum will be always equal to mm->exec_vm which sums size of
>>> executable and not writable and not stack areas.
>>
>> When does this happen?  What causes start_code/end_code to get "screwed"?
> 
> I don't know exactly what happened.
> I've seen this for huge (>2Gb) statically linked binary which has whole world inside.
> 
> For it start_code .. end_code range also covers one of rodata sections.
> Probably this is bug in customized linker, elf loader or both.
> 
> Anyway CONFIG_CHECKPOINT_RESTORE allows to change these pointers,
> thus we cannot trust them without validation.

Please add this to changelog. I agree that it's better/safer after your
patch. These counters are fundamentally heuristics so we can't guarantee
"proper" values for weird binaries. exec_vm OTOH is an objective value
so it makes sense to use it as a safe boundary.

Acked-by: Vlastimil Babka <vbabka@...e.cz>

>>
>> When these pointers are screwed, the result of end_code-start_code can
>> still be wrong while not necessarily being negative, yes?  In which
>> case we'll still display incorrect output?
>>
> 
> Here we split exec_vm into main code segment and libraries.
> 
> Range start_code .. end_code declared as main code segment.
> In my case it's bigger than exec_vm, so libraries have to be negative.
> 
> After my patch libraries will be 0 and whole exec_vm show as VmExe.
> At least sum VmExe + VmLib stays correct and both of them sane.
> 
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majordomo@...ck.org.  For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: <a href=mailto:"dont@...ck.org"> email@...ck.org </a>
>