Re: [PATCH 1/2] compat32: translate userland PT_* request values into kernel

2019-05-29 Thread Michał Górny
On Thu, 2019-05-30 at 03:15 +1000, matthew green wrote:
> thanks for working on this.
> 
> > +   case PT_FIRSTMACH + 0:
> > +   return PT_STEP;
> > +   case PT_FIRSTMACH + 1:
> > +   return PT_GETREGS;
> [ ... ]
> 
> these magic numbers are a little ugly.  can you avoid them?

I know they are, however I don't think it's really possible.  One option
is to declare additional set of constants in the amd64 headers but that
doesn't really gain us anything, and ends up in kinda-absurd:

  case PT32_STEP: return PT_STEP;

or alike.

> is there a way to have amd64 have direct access to the i386
> values?

I don't think so.

> > --- a/sys/sys/ptrace.h
> > +++ b/sys/sys/ptrace.h
> > @@ -283,6 +283,10 @@ intptrace_machdep_dorequest(struct lwp *, struct 
> > lwp *, int,
> >  #define FIX_SSTEP(p)
> >  #endif
> >  
> > +#ifndef PTRACE_TRANSLATE_REQUEST32
> > +#define PTRACE_TRANSLATE_REQUEST32(x) x
> > +#endif
> > +
> 
> can this part live in sys/compat(/netbsd32)?  no need for the
> public ptrace header to get this, right?
> 

I'll try and see.

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


re: [PATCH 1/2] compat32: translate userland PT_* request values into kernel

2019-05-29 Thread matthew green
thanks for working on this.

> + case PT_FIRSTMACH + 0:
> + return PT_STEP;
> + case PT_FIRSTMACH + 1:
> + return PT_GETREGS;
[ ... ]

these magic numbers are a little ugly.  can you avoid them?
is there a way to have amd64 have direct access to the i386
values?

> --- a/sys/sys/ptrace.h
> +++ b/sys/sys/ptrace.h
> @@ -283,6 +283,10 @@ int  ptrace_machdep_dorequest(struct lwp *, struct 
> lwp *, int,
>  #define FIX_SSTEP(p)
>  #endif
>  
> +#ifndef PTRACE_TRANSLATE_REQUEST32
> +#define PTRACE_TRANSLATE_REQUEST32(x) x
> +#endif
> +

can this part live in sys/compat(/netbsd32)?  no need for the
public ptrace header to get this, right?


.mrg.


Re: [PATCH 1/2] compat32: translate userland PT_* request values into kernel

2019-05-28 Thread Kamil Rytarowski
On 27.05.2019 21:03, Michał Górny wrote:
> Currently, the compat32 passes PT_* request values to kernel functions
> without translation.  This works fine for low PT_* requests that happen
> to have the same values both on i386 and amd64.  However, for requests
> higher than PT_SETFPREGS, the value passed from userland (matching i386
> const) does not match the correct kernel (amd64) request.  As a result,
> e.g. when compat32 process calls PT_GETDBREGS, kernel actually processes
> it as PT_SETSTEP.
> 
> To resolve this, introduce support for compat32 PT_* request
> translation.  The interface is based on PTRACE_TRANSLATE_REQUEST32 macro
> that is defined to a mapping function on architectures needing it.
> In case of amd64, this function maps userland i386 PT_* values into
> appropriate amd64 PT_* values.
> 
> For the time being, the two additional PT_GETXMMREGS and PT_SETXMMREGS
> requests are unsupported due to lack of matching free amd64 constant.


Both patches look good to me.



signature.asc
Description: OpenPGP digital signature