On 07/03/2011 11:34 AM, Alexander Graf wrote:
>>
>> Yup, which requires knowledge in the code on what actually fits :). Logic
we don't have today.
>
> I don't follow. What knowledge is required? Please give an example.
Sure. Let's take an easy example Currently we have for get_pvinfo:
<snip>
The padding would not be there with your idea. An updated version could look
like this:
/* for KVM_PPC_GET_PVINFO */
struct kvm_ppc_pvinfo {
/* out */
__u32 flags;
__u32 hcall[4];
__u64 features; /* only there with PVINFO_FLAGS_FEATURES */
};
Now, your idea was to not use copy_from/to_user directly, but instead some
wrapper that could pad with zeros on read or truncate on write. So instead we
would essentially get:
int kvm_vm_ioctl_get_pvinfo(struct kvm_ppc_pvinfo *pvinfo, int
*required_size)
{
[...]
if (pvinfo_flags& PVINFO_FLAGS_FEATURES) {
*required_size = 16;
} else {
*required_size = 8;
}
[...]
}
Why? Kernel code would only consider the full structure.
case KVM_PPC_GET_PVINFO: {
struct kvm_ppc_pvinfo pvinfo;
int required_size = 0;
memset(&pvinfo, 0, sizeof(pvinfo));
r = kvm_vm_ioctl_get_pvinfo(&pvinfo,&required_size);
if (copy_to_user(argp,&pvinfo, required_size) {
r = -EFAULT;
goto out;
}
required_size would come from the size encoded in the ioctl number, no
need to calculate it separately.
break;
}
Otherwise we might write over data the user expected. And that logic that tells
to copy_to_user how much data it actually takes to put all the information in
is not there today and would have to be added. You can even verify that
required_size with the ioctl passed size to make 100% sure user space is sane,
but I'd claim that a feature bitmap is plenty of information to ensure that
we're not doing something stupid.
I don't see why we have to caclulate something, then verify it against
the correct answer.
--
error compiling committee.c: too many arguments to function
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev