linux-kernel - Re: [PATCH v15 04/10] arm64: Kprobes with single stepping support

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: <20160727133831.GD17195@leverpostej>
Date:	Wed, 27 Jul 2016 14:38:31 +0100
From:	Mark Rutland <mark.rutland@....com>
To:	Daniel Thompson <daniel.thompson@...aro.org>
Cc:	Catalin Marinas <catalin.marinas@....com>,
	David Long <dave.long@...aro.org>,
	Petr Mladek <pmladek@...e.com>,
	Zi Shen Lim <zlim.lnx@...il.com>,
	Will Deacon <will.deacon@....com>,
	Andrey Ryabinin <ryabinin.a.a@...il.com>,
	yalin wang <yalin.wang2010@...il.com>,
	Li Bin <huawei.libin@...wei.com>,
	John Blackwood <john.blackwood@...r.com>,
	Pratyush Anand <panand@...hat.com>,
	Huang Shijie <shijie.huang@....com>,
	Dave P Martin <Dave.Martin@....com>,
	Jisheng Zhang <jszhang@...vell.com>,
	Vladimir Murzin <Vladimir.Murzin@....com>,
	Steve Capper <steve.capper@...aro.org>,
	Suzuki K Poulose <suzuki.poulose@....com>,
	Marc Zyngier <marc.zyngier@....com>,
	Yang Shi <yang.shi@...aro.org>,
	Mark Brown <broonie@...nel.org>,
	Sandeepa Prabhu <sandeepa.s.prabhu@...il.com>,
	William Cohen <wcohen@...hat.com>,
	Alex Bennée <alex.bennee@...aro.org>,
	Adam Buchbinder <adam.buchbinder@...il.com>,
	linux-arm-kernel@...ts.infradead.org,
	Ard Biesheuvel <ard.biesheuvel@...aro.org>,
	linux-kernel@...r.kernel.org, James Morse <james.morse@....com>,
	Masami Hiramatsu <mhiramat@...nel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Robin Murphy <robin.murphy@....com>,
	Jens Wiklander <jens.wiklander@...aro.org>,
	Christoffer Dall <christoffer.dall@...aro.org>
Subject: Re: [PATCH v15 04/10] arm64: Kprobes with single stepping support

On Wed, Jul 27, 2016 at 12:19:59PM +0100, Daniel Thompson wrote:
> On 26/07/16 18:54, Mark Rutland wrote:
> >On Tue, Jul 26, 2016 at 10:50:08AM +0100, Daniel Thompson wrote:
> >>On 25/07/16 18:13, Catalin Marinas wrote:
> >>>You get more unexpected side effects by not saving/restoring the whole
> >>>stack. We looked into this on Friday and came to the conclusion that
> >>>there is no safe way for kprobes to know which arguments passed on the
> >>>stack should be preserved, at least not with the current API.
> >>>
> >>>Basically the AArch64 PCS states that for arguments passed on the stack
> >>>(e.g. they can't fit in registers), the caller allocates memory for them
> >>>(on its own stack) and passes the pointer to the callee. Unfortunately,
> >>>the frame pointer seems to be decremented correspondingly to cover the
> >>>arguments, so we don't really have a way to tell how much to copy.
> >>>Copying just the caller's stack frame isn't safe either since a
> >>>callee/caller receiving such argument on the stack may passed it down to
> >>>a callee without copying (I couldn't find anything in the PCS stating
> >>>that this isn't allowed).
> >>
> >>The PCS[1] seems (at least to me) to be pretty clear that "the
> >>address of the first stacked argument is defined to be the initial
> >>value of SP".
> >>
> >>I think it is only the return value (when stacked via the x8
> >>pointer) that can be passed through an intermediate function in the
> >>way described above. Isn't it OK for a jprobe to clobber this
> >>memory? The underlying function will overwrite whatever the jprobe
> >>put there anyway.
> >>
> >>Am I overlooking some additional detail in the PCS?
> >
> >I suspect that the "initial value of SP" is simply meant to be relative to the
> >base of the region of stack reserved for callee parameters. While it also uses
> >the phrase "current stack-pointer value", I suspect that this is overly
> >prescriptive.
> 
> I don't think so. Whilst writing my reply of yesterday I forced
> stacked arguments by creating a function with nine arguments (rather
> than large values). The ninth argument is, as expected, passed to
> the callee based on the value of the SP.

Ah. I'd failed to fully appreciate the distinction between large
structures (which get converted to pointers), and basic argument types
(including those converted pointers).

For basic argument types, I think you're right, and my wording above is
wrong.

However, for (large enough) structures I don't think we have any
guarantee as to their location.

Sorry for the confusion there!

Mark.