linux-kernel - Re: [PATCH] s390/perf: fix 'start' address of module's map

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] [day] [month] [year] [list]

Message-Id: <b9553153-32d8-ef79-f438-44d1b5674ad6@linux.vnet.ibm.com>
Date:	Thu, 28 Jul 2016 10:01:27 +0800
From:	Songshan Gong <gongss@...ux.vnet.ibm.com>
To:	Arnaldo Carvalho de Melo <acme@...nel.org>
Cc:	Christian Borntraeger <borntraeger@...ibm.com>, jolsa@...nel.org,
	dsahern@...il.com, linux-kernel@...r.kernel.org,
	Michael Ellerman <mpe@...erman.id.au>
Subject: Re: [PATCH] s390/perf: fix 'start' address of module's map



在 7/27/2016 9:08 PM, Arnaldo Carvalho de Melo 写道:
> Em Wed, Jul 27, 2016 at 06:49:48PM +0800, Songshan Gong escreveu:
>>
>>
>> 在 7/27/2016 4:29 AM, Arnaldo Carvalho de Melo 写道:
>>> Em Tue, Jul 26, 2016 at 10:14:18PM +0200, Christian Borntraeger escreveu:
>>>> On 07/26/2016 09:50 PM, Arnaldo Carvalho de Melo wrote:
>>>>> Em Thu, Jul 21, 2016 at 11:10:51AM +0800, Song Shan Gong escreveu:
>>>>>> At preset, when creating module's map, perf gets 'start' address by parsing
>>>>>> '/proc/modules', but it's module base address, isn't the start address of
>>>>>> '.text' section. In most archs, it's OK. But for s390, it places 'GOT' and
>>>>>> 'PLT' relocations before '.text' section. So there exists an offset between
>>>>>> module base address and '.text' section, which will incur wrong symbol
>>>>>> resolution for modules.
>>>>>
>>>>> I'll apply this as it fixes the problem for you and we need to get fixes
>>>>> in ASAP to get this into 4.8, but why can't we just use your method for
>>>>> all arches and get rid of this arch__ hook? I.e. if I look here in my
>>>>> x86_64 notebook I see:
>>>>>
>>>>> [acme@...et linux]$ cat /sys/module/tun/sections/.text
>>>>> 0xffffffffc0af2000
>>>>> [acme@...et linux]$ grep tun /proc/modules
>>>>> tun 28672 4 vhost_net, Live 0xffffffffc0af2000
>>>>> [acme@...et linux]$
>>>>>
>>>>> So I could as well use what is in /sys/module/tun/sections/.text instead
>>>>> of reading it from /proc/modules and, in s390, reading it from
>>>>> /sys/module/tun/sections/.text.
>>>>>
>>>>> Do you see any problem with using this approach for _all_ arches?
>>>>
>>>> I think it should work well for _all_ arches but it will probably be
>>>> hard to test this without help.
>>>
>>> Well, we could check for the cases we don't know, i.e. read from both
>>> and warn about cases where it is different, except for s390 where we now
>>> which is the right one to pick.
>>>
>> One question: how to get arch info except machine->env->arch? It seems that
>> machine->env->arch could be NULL sometimes.
>
> That is not what you want to look at, as it is related to perf.data,
> which may not be related to what you want, which is the running machine.
>
> For that use uname() -> utsname.machine.
>
> But then, why would you need it for reading /sys/module/*/sections/.text?
> The arch name isn't there :-)

Yes, it's no use for this patch. Thanks a lot.
>
> - Arnaldo
>

-- 
SongShan Gong