linux-kernel - Re: BUG: perf error on syscalls for powerpc64.

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, 21 Jul 2015 16:40:21 +1000
From:	Michael Ellerman <mpe@...erman.id.au>
To:	Zumeng Chen <zumeng.chen@...driver.com>
Cc:	Zumeng Chen <zumeng.chen@...il.com>, linux-kernel@...r.kernel.org,
	paulus@...ba.org, imunsie@....ibm.com,
	linuxppc-dev@...ts.ozlabs.org, romeo.cane.ext@...iant.com,
	Anton Blanchard <anton@...ba.org>
Subject: Re: BUG: perf error on syscalls for powerpc64.

On Fri, 2015-07-17 at 13:28 +0800, Zumeng Chen wrote:
> On 2015年07月17日 12:07, Michael Ellerman wrote:
> > On Fri, 2015-07-17 at 09:27 +0800, Zumeng Chen wrote:
> >> On 2015年07月16日 17:04, Michael Ellerman wrote:
> >>> On Thu, 2015-07-16 at 13:57 +0800, Zumeng Chen wrote:
> >>>> Hi All,
> >>>>
> >>>> 1028ccf5 did a change for sys_call_table from a pointer to an array of
> >>>> unsigned long, I think it's not proper, here is my reason:
> >>>>
> >>>> sys_call_table defined as a label in assembler should be pointer array
> >>>> rather than an array as described in 1028ccf5. If we defined it as an
> >>>> array, then arch_syscall_addr will return the address of sys_call_table[],
> >>>> actually the content of sys_call_table[] is demanded by arch_syscall_addr.
> >>>> so 'perf list' will ignore all syscalls since find_syscall_meta will
> >>>> return null
> >>>> in init_ftrace_syscalls because of the wrong arch_syscall_addr.
> >>>>
> >>>> Did I miss something, or Gcc compiler has done something newer ?
> >>> Hi Zumeng,
> >>>
> >>> It works for me with the code as it is in mainline.
> >>>
> >>> I don't quite follow your explanation, so if you're seeing a bug please send
> >>> some information about what you're actually seeing. And include the disassembly
> >>> of arch_syscall_addr() and your compiler version etc.
> >> Hi Michael,
> > Hi Zumeng,
> >
> >> Yeah, it seems it was not a good explanation, I'll explain more this time:
> >>
> >> 1. Whatever we exclaim sys_call_table in C level, actually it is a pointer
> >>       to sys_call_table rather than sys_call_table self in assemble level.
> > No it's not a pointer.
> 
> Then what is the second one in the following:

It's a function descriptor.

> zchen@...-yocto-build2:$ cat  System.map |grep sys_call_table
> c000000000009590 T .sys_call_table  <-----this is a real sys_call_table.
> c0000000014e1b48 D sys_call_table  <-----this should be referred by 
> arch_syscall_addr
> 
> The c0000000014e1b48[0] = c000000000009590

That is from 3.14 isn't it?

In 3.14 we had in systbl.S:

    46 _GLOBAL(sys_call_table)
    47 #include <asm/systbl.h>

And _GLOBAL was:

    46 #define _GLOBAL(name) \
    47         .type name,@function; \
    48         .globl name; \
    49 name:


Which means sys_call_table was being declared as a function, which is
completely wrong.

On big endian when you declare a function "foo" you get two symbols, ".foo" at
the address you declare the symbol and "foo" which is somewhere else and
contains three pointers, the first of which is to ".foo".

So at address "foo" you have a pointer to ".foo", which happens to be what
you'd expect if "foo" was a pointer to ".foo".

Anton fixed this in 3.16:

  https://git.kernel.org/torvalds/c/c857c43b34ec


But that had the side-effect of breaking the usage of sys_call_table in C.

cheers


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