Hello, On Wed, 05 Oct 2022 13:37:35 +0900 (JST) Masato Asou <a...@soum.co.jp> wrote: > From: "Theo de Raadt" <dera...@openbsd.org> > Date: Tue, 04 Oct 2022 21:58:13 -0600 >> Userland may not ask the kernel to allocate such a huge object. The >> kernel address space is quite small. First off, huge allocations will >> fail. >> >> But it is worse -- the small kernel address space is shared for many >> purposes, so large allocations will harm the other subsystems. >> >> As written, this diff is too dangerous. Arbitrary allocation inside >> the kernel is not reasonable. object sizes requested by userland must >> be small, or the operations must be cut up, which does create impact >> on atomicity or other things. > > As you pointed out, it is not a good idea to allocate large spaces > in kernel. > > Would it be better to keep the current fixed length?
Currently the value on VMware may be truncated silently. It's simply broken. I think we should fix it by having a way to know if the value is reached the limit. Also I think we should be able to pass larger size of data. Since at least on VMware, people is useing for parameters when deployment through OVF tamplate. Sometimes the parameter includes large data like X.509 certificate. https://docs.vmware.com/en/VMware-vSphere/7.0/com.vmware.vsphere.vm_admin.doc/GUID-D0F9E3B9-B77B-4DEF-A982-49B9F6358FF3.html What do you think? > Prepare a variable like kern.maxpvbus and default it to > 4096. Futhermore, how about free() after copyout() to user space? I suppose we can use the space prepared by the userland directly.
