linux-kernel - Re: [V6,1/9] elf: Add new powerpc specifc core note sections

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:	Fri, 23 Jan 2015 08:44:09 +1100
From:	Michael Neuling <mikey@...ling.org>
To:	Ulrich Weigand <Ulrich.Weigand@...ibm.com>
Cc:	akpm@...ux-foundation.org, avagin@...nvz.org, davej@...hat.com,
	davem@...emloft.net, dhowells@...hat.com,
	Edjunior Barbosa Machado <emachado@...ux.vnet.ibm.com>,
	james.hogan@...tec.com,
	Anshuman Khandual <khandual@...ux.vnet.ibm.com>,
	kirjanov@...il.com, linux-kernel@...r.kernel.org,
	linuxppc-dev@...abs.org, Michael Ellerman <mpe@...erman.id.au>,
	oleg@...hat.com, palves@...hat.com, Paul.Clothier@...tec.com,
	peterz@...radead.org, sam.bobroff@....ibm.com,
	shuahkh@....samsung.com, sukadev@...ux.vnet.ibm.com,
	tglx@...utronix.de
Subject: Re: [V6,1/9] elf: Add new powerpc specifc core note sections

> > > Inside transaction both running and check pointed values can be
> > > probed independently.
> >
> > Yep, that's the idea, although setting the running values won't change
> > anything since the the translation is already doomed and will abort once
> > the cpu starts executing it.
> 
> So this looks to me like the overall effect on debugging transactional
> code should be the same on Power and z, even if some internal details
> are different (on z, the exception will automatically abort the
> transaction; on p, the exception itself will not abort, but *restarting*
> user space execution will).

Yep

> From a GDB perspective, it would therefore be preferable if the ptrace
> interface were to behave in a similar fashion on p as on z: that is,
> if an exception interrupting a transaction results in a ptrace intercept,
> at this point:

Agreed.

> - the "normal" ptrace register set commands should access the
>   *checkpointed* registers (allowing both read and write access)

OK, this is a change from what we've been proposing with Anshuman's
patch set but I'm happy to change it to make it consistent with other
architectures.  It's relatively arbitrary which goes where, so I'm happy
to change.

>   -- GDB will use this to display current position (already reflecting
>   the fact that the transaction will abort), and use it when changing
>   register values e.g. to effect an inferior function call

"Current position" depends on your perspective.  Is it the last executed
instruction or the next executed instruction?  If it's the last executed
instruction, then it's the running values.  If it's the next, then it's
the check pointed.  

Anyway, I'm happy to make it the check pointed values for the sake of
ptrace/gdb.

> - a new ptrace register set should allow access (read-only) to the
>   *running* register values

This is because changing them won't ever result in a side effect?  

>   -- GDB can use this to display the position inside the transaction
>   at the point it aborted, using new transaction-specific commands

Yep.

Mikey

PS in the subject s/specifc/specific/
--
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/