Extending MADV_PROTECT
John Baldwin
jhb at FreeBSD.org
Mon May 13 20:12:02 UTC 2013
On 5/11/13 12:36 AM, Konstantin Belousov wrote:
> On Fri, May 10, 2013 at 03:35:50PM -0400, John Baldwin wrote:
>> Ok, here is a patch for 8 that reworks this to use a procctl(). If this looks
>> reasonable I will port this to HEAD as two pieces: the first to add
>> procctl() and the second to add PROCSPROTECT.
>
> This looks fine.
>
> Do we need the genericity of the ioctl for procctl ?
> Ptrace(2) does not need the size encoded.
>
> I mean, the call is never marshalled to some unknown driver which needs
> a size of parameters unknown to the generic layer. I suppose that all
> additions to procctl() would have the size of the control structures
> pre-defined. Then, you could just do copyin and, if needed, copyout
> discrimating on the command code, and not on the encoding of the size in
> the command.
>
> Also, command could be int and not long then, eliminating the need for
> compat32 wrapper.
Well, the generic-ness of ioctl() seemed useful to me. Also, I think
with this model you could make fo_ioctl() for a process fd just do this:
proc_ioctl(..., u_long cmd, caddr_t data)
{
pid = <get pid from f_data>;
return (kern_procctl(td, P_PID, pid, cmd, data));
}
So you could reuse procctl constants as ioctls for proc descriptors. It
is true that unlike drivers there is currently no method to provide a
"hook" to support new commands (they would just have to be added by hand
into sys_process.c for now). Also, if we need to "thunk" structures for
compat32 support in the future it is better if the kern_procctl()
version takes a KVA rather than a UVA.
OTOH, it is more boilerplate code to put in.
In terms of a compat32 wrapper: id_t is a uint64_t, so a wrapper would
be required regardless.
--
John Baldwin
More information about the freebsd-arch
mailing list