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: <1426718702.4866.2.camel@neuling.org>
Date:	Thu, 19 Mar 2015 09:45:02 +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 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.

Thanks!
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/