On 03.07.2011, at 10:56, Avi Kivity wrote: > 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. Ah, I think I'm grasping your idea. You'd simply truncate the resulting struct according to the size passed by the ioctl and call it a day. Well, that works too. User space simply wouldn't be able to know if all information actually fit into the struct, but I guess that's fine :). Alex -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html