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: <1418204242.9279.4.camel@ellerman.id.au>
Date:	Wed, 10 Dec 2014 20:37:22 +1100
From:	Michael Ellerman <mpe@...erman.id.au>
To:	"Naveen N. Rao" <naveen.n.rao@...ux.vnet.ibm.com>
Cc:	linuxppc-dev@...ts.ozlabs.org, linux-kernel@...r.kernel.org,
	acme@...nel.org, ananth@...ibm.com
Subject: Re: [RFC PATCH 1/8] kprobes: Fix kallsyms lookup across powerpc
 ABIv1 and ABIv2

On Tue, 2014-12-09 at 23:03 +0530, Naveen N. Rao wrote:
> Currently, all non-dot symbols are being treated as function descriptors
> in ABIv1. This is incorrect and is resulting in perf probe not working:

I don't understand that first sentence. With ABIv1 non-dot symbols *are*
function descriptors?

>   # perf probe do_fork
>   Added new event:
>   Failed to write event: Invalid argument
>     Error: Failed to add events.
>   # dmesg | tail -1
>   [192268.073063] Could not insert probe at _text+768432: -22
> 
> _text is being resolved incorrectly and is resulting in the above error.
> Fix this by changing how we lookup symbol addresses on ppc64. We first
> check for the dot variant of a symbol and look at the non-dot variant
> only if that fails. In this manner, we avoid having to look at the
> function descriptor.

I'm not clear that ppc_local_function_entry() makes sense. On ABIv2 you return
the local entry point, which is fine. But on ABIv1 you just return the
unmodified address, which will be the descriptor if you actually passed it a
function pointer. I think you're assuming that you're passed the text address,
but if that's the case the function is badly named at least.

I also don't understand why we need to ever guess which ABI we're using. We
know which ABI we're built with, so there should be no guess work required.

So at the very least this needs much more explanation.

But to be honest I'm not clear why it even needs a kernel change, don't we just
need perf to understand dot symbols?

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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ