[PATCH 0/2] powerpc: Disable syscall emulation and stepping
Naveen N. Rao
naveen.n.rao at linux.vnet.ibm.com
Fri Jan 28 22:15:51 AEDT 2022
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
More information about the Linuxppc-dev
mailing list