On 08.12.2016 02:56, Rin Okuyama wrote:
> Thank you very much for your kind explanation.
>
> On 2016/12/07 13:26, Kamil Rytarowski wrote:
>> On 07.12.2016 04:27, Rin Okuyama wrote:
>>> However, before proceeding further, we need to discuss undocumented
>>> details related to PT_STEP; What should we do when a process steps into
>>> a RAS? How about the case where PT_STEP is used against a process which
>>> is already in single stepping? And so on...
>>>
>>
>> According to my understanding RAS is intended to be atomic sequence of
>> operations and tracer mustn't interrupt or preempt it.
>
> process_sstep(9) should fail and return EFAULT in such a case?
>
>> There might exist only single tracer attached to a process.
>>
>> I don't think PT_STEP called twice for the same process makes sense in
>> real life, it might be undefined behavior on port-specific basis and/or
>> return error (in other words just prevent panic(9) and vulnerabilities).
>> If I remember correctly process sets MD-style PSL_T variable to indicate
>> trap after at least single instruction - if so, we cannot set this bit
>> twice.
>
> Yes, it makes no sense. In my patch for powerpc/ibm4xx, process_sstep(9)
> just returns 0 in that case. But I come to feel EFAULT more preferable.
>
> rin
PT_STEP is restricted to stopped processes and return EBUSY. I've not
been checking whether there is time window to sidestep it, if so I would
rather try to eliminate it rather than handle it in MD-specific code.
467 /*
468 * (4) it's not currently stopped.
469 */
470 if (t->p_stat != SSTOP || !t->p_waited /* XXXSMP */) {
471 DPRINTF(("stat %d flag %d\n", t->p_stat,
472 !t->p_waited));
473 error = EBUSY;
474 break;
475 }
-- src/sys/kern/sys_ptrace_common.c
Attachment:
signature.asc
Description: OpenPGP digital signature