Re: [PATCH 0/2] powerpc: Disable syscall emulation and stepping

["Naveen N. Rao" <naveen.n.rao@linux.vnet.ibm.com>]

On 2022-01-27 13:09, Nicholas Piggin wrote:
> Excerpts from naverao1's message of January 25, 2022 8:48 pm:
>> On 2022-01-25 11:23, Christophe Leroy wrote:
>>> Le 25/01/2022 à 04:04, Nicholas Piggin a écrit :
>>>> +Naveen (sorry missed cc'ing you at first)
>>>> 
>>>> Excerpts from Christophe Leroy's message of January 24, 2022 4:39 
>>>> pm:
>>>>> 
>>>>> 
>>>>> Le 24/01/2022 à 06:57, Nicholas Piggin a écrit :
>>>>>> As discussed previously
>>>>>> 
>>>>>> https://lists.ozlabs.org/pipermail/linuxppc-dev/2022-January/238946.html
>>>>>> 
>>>>>> I'm wondering whether PPC32 should be returning -1 for syscall
>>>>>> instructions too here? That could be done in another patch anyway.
>>>>>> 
>>>>> 
>>>>> The 'Programming Environments Manual for 32-Bit Implementations of
>>>>> the
>>>>> PowerPC™ Architecture' says:
>>>>> 
>>>>> The following are not traced:
>>>>> • rfi instruction
>>>>> • sc and trap instructions that trap
>>>>> • Other instructions that cause interrupts (other than trace
>>>>> interrupts)
>>>>> • The first instruction of any interrupt handler
>>>>> • Instructions that are emulated by software
>>>>> 
>>>>> 
>>>>> So I think PPC32 should return -1 as well.
>>>> 
>>>> I agree.
>>>> 
>>>> What about the trap instructions? analyse_instr returns 0 for them
>>>> which falls through to return 0 for emulate_step, should they
>>>> return -1 as well or am I missing something?
>> 
>> Yeah, good point about the trap instructions.
>> 
>>>> 
>>> 
>>> For the traps I don't know. The manual says "trap instructions that
>>> trap" are not traced. It means that "trap instructions that _don't_
>>> trap" are traced. Taking into account that trap instructions don't 
>>> trap
>>> at least 99.9% of the time, not sure if returning -1 is needed.
>>> 
>>> Allthought that'd probably be the safest.
>> 
>> 'trap' is a special case since it is predominantly used by debuggers
>> and/or tracing infrastructure. Kprobes and Uprobes do not allow probes
>> on a trap instruction. But, xmon can be asked to step on a trap
>> instruction and that can interfere with kprobes in weird ways.
>> 
>> So, I think it is best if we also exclude trap instructions from being
>> single stepped.
>> 
>>> 
>>> But then what happens with other instruction that will sparsely
>>> generate
>>> an exception like a DSI or so ? If we do it for the traps then we
>>> should
>>> do it for this as well, and then it becomes a non ending story.
>> 
>> For a DSI, we restart the same instruction after handling the page
>> fault.
>> The single step exception is raised on the subsequent successful
>> completion of the instruction.
> 
> Although it can cause a signal, and the signal handler can decide
> to resume somewhere else.

If a signal is generated while we are single-stepping, we delay signal
delivery (see uprobe_deny_signal()) until after the single stepping.
For fatal signals, single stepping is disabled before we allow the
signal to be delivered.

> Or kernel mode equivalent it can go to a
> fixup handler and resume somewhere else.

For kprobes, we do not allow probing instructions that have an extable
entry.

- Naveen