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: <550FEC36.8080803@linux.vnet.ibm.com>
Date:	Mon, 23 Mar 2015 16:04:30 +0530
From:	Anshuman Khandual <khandual@...ux.vnet.ibm.com>
To:	Michael Neuling <mikey@...ling.org>,
	Ulrich Weigand <Ulrich.Weigand@...ibm.com>
CC:	shuahkh@....samsung.com, james.hogan@...tec.com, avagin@...nvz.org,
	Paul.Clothier@...tec.com, peterz@...radead.org,
	linux-kernel@...r.kernel.org, davem@...emloft.net,
	dhowells@...hat.com, linuxppc-dev@...abs.org, kirjanov@...il.com,
	tglx@...utronix.de, oleg@...hat.com, sukadev@...ux.vnet.ibm.com,
	davej@...hat.com, akpm@...ux-foundation.org, palves@...hat.com,
	Edjunior Barbosa Machado <emachado@...ux.vnet.ibm.com>,
	sam.bobroff@....ibm.com
Subject: Re: [V6,1/9] elf: Add new powerpc specifc core note sections

On 03/19/2015 04:20 AM, Michael Neuling wrote:
> 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.

No, we dont have that yet. When ptracing in 32-bit mode the MSR value
which can be viewed or set from the user space through PTRACE_GETREGS
PTRACE_SETREGS call is it's lower 32 bits only. Either we can club
the upper 32 bits of MSR as part of one of the ELF core notes we are
adding in the patch series or we can create one more separate ELF core
note for that purpose. Let me know your opinion on this.

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