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]

Message-ID: <1422419289.9646.20.camel@neuling.org>
Date:	Wed, 28 Jan 2015 15:28: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

On Fri, 2015-01-23 at 08:44 +1100, Michael Neuling wrote:
> > > > 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.

Uli,

Sorry, I'm rethinking this as we didn't consider user suspended
transactions.

It makes sense for normal transactions but for user suspended
transactions the running values are the ones you want to modify since
that is where you'll end up restarting from.  The hardware will only
abort/rollback once a tresume is encountered.
      * 
So we could do what you're talking about for normal transactions and
then switch them for suspended transactions.  But this just seems to be
making the kernel interface overly complicated.  

So I'm keen on just keeping it the way Anshuman has now and GDB has to
understand the program flow better to know which ones it wants to
modify.  The kernel always provides the "normal" set as running and the
new set as check pointed.  GDB then has to check the MSR to work out
what it wants to modify.

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

For the same reason as above, we need to be able to modify the running
values when it's a user suspended transaction.  So I don't agree with
this any more in the case of user suspended transaction.  We need to be
able to modify both sets of registers.

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