linux-kernel - Re: perf's handling of unfindable user symbols...

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]

Message-Id: <20181015.160246.58484704665215987.davem@davemloft.net>
Date:   Mon, 15 Oct 2018 16:02:46 -0700 (PDT)
From:   David Miller <davem@...emloft.net>
To:     acme@...hat.com
Cc:     linux-kernel@...r.kernel.org, acme@...nel.org
Subject: Re: perf's handling of unfindable user symbols...

From: Arnaldo Carvalho de Melo <acme@...hat.com>
Date: Mon, 15 Oct 2018 19:25:46 -0300

> But I think we should have it as a property of 'struct machine', because we may
> be processing on, say, x86, a perf.data file recorded on a Sparc machine, so we
> need to save this property on the perf.data file, humm, or we can derive that
> from data already there, like the quick patch below. I'll cache that property
> on machine->user_kernel_shared_address_space, to avoid having to do the
> strcmp() lots of times.
> 
> Does that document the hack further? Defining the
> machine__user_kernel_shared_address_space() function right besides the
> machine__kernel_ip() inline should help as well?

Your patch looks fine.

But, more deeply, the VDSO thing itself makes no sense to me.

Why would we use the kernel map for something that is mapped into
userspace and uses the user space virtual addresse range?

As it is used by user applications, the VDSO isn't mapped into the
kernel virtual address range, therefore no PC from userspace executing
the VDSO will have a kernel range address.

We will see normal userspace virtual addresses instead.  Test this
assertion, if you like :-)

So I am suggesting that we remove the hack, and don't try to use the
kernel map for resolving the IP of user mode events.  If that is a
valid change, we can toss all of this weird stuff that tries to
interpret an address based upon what "range" it falls into.