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: <1426719027.4866.4.camel@neuling.org>
Date:	Thu, 19 Mar 2015 09:50:27 +1100
From:	Michael Neuling <mikey@...ling.org>
To:	Ulrich Weigand <Ulrich.Weigand@...ibm.com>,
	Anshuman Khandual <khandual@...ux.vnet.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 Thu, 2015-03-19 at 09:45 +1100, Michael Neuling wrote:
> On Wed, 2015-03-18 at 13:53 +0100, Ulrich Weigand wrote:
> > Michael Neuling <mikey@...ling.org> wrote on 23.02.2015 05:51:50:
> > 
> > > Sorry for the slow response.
> > 
> > Same here :-(
> 
> I'm going to break the cycle and respond in a few hours :-)
> 
> 
> > > I think what you're proposing with running the inferior function in
> > > suspend mode may end up corrupting the stack in this way.  You'd need to
> > > be really careful to make sure the inferior function is run on the stack
> > > pointer of the checkpointed registers.
> > 
> > On the other hand, if code called a subroutine after the tbegin, if we
> > were using the checkpointed r1, this might corrupt the stack of the
> > transactional code.  (This code will never actually *run* again since
> > the transaction is doomed, but we can still *inspect* it in GDB after
> > the inferior call has returned, so the stack should remain unchanged.
> > Well .. if the transaction is suspended, the code might in fact still
> > run, so it should remain unchanged either way.)
> > 
> > I guess we could use the minimum of transactional and checkpointed r1
> > in that case, to be safe either way.
> 
> Sounds good.
> 
> <snip>
> 
> > > > Using the combination of (A)+(A') would be easiest to implement
> > > > in GDB without modifying a lot of common code, and would have the
> > > > advantage that the inferior function always executes in the same
> > > > state (suspended), while leaving information about the interrupted
> > > > transaction visible.
> > > >
> > > > Using the combination of (B)+(B') would be a bit more difficult
> > > > to implement (but certainly feasible), and would have the advantage
> > > > that the inferior function always executes in nontransactional state
> > > > (which is what it would most likely expect, anyway).  However, the
> > > > disadvantage is that after the inferior call returns, GDB is unable
> > > > to fully restore the visible inferior state as it was before (since
> > > > we're now in nontransactional state, and there is probably no way
> > > > to force us back into transactional/suspended state ...).
> > >
> > > Yep.
> > 
> > So right now I'd tend to prefer (A)+(A'), but the important thing is
> > that the kernel seems to provide all features required for GDB to
> > implement any of the above, so we can still make that decision later.
> > 
> > > Getting back to the kernel interface, are you happy with what Anshuman
> > > has proposed in the current series?
> > 
> > Given the discussion above, this seems fine to me now.
> 
> Great, we'll push through with this in mind.

Anshuman,

With that in mind, do we have a way to set the top 32bits of the MSR
(which contain the TM bits) when ptracing 32 bit processes?  I can't
find anything like that in this patch set.  

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/