On Fri, Jun 12, 2020 at 08:28:16PM +0200, Christian Brauner wrote: > Al didn't want the PAGE_SIZE limit in there because there's nothing > inherently wrong with copying insane amounts of memory. Right, ok. > (Another tangent. I've asked this on Twitter not too long ago: do we > have stats how long copy_from_user()/copy_struct_from_user() takes with > growing struct/memory size? I'd be really interested in this. I have a > feeling that clone3()'s and - having had a chat with David Howells - > openat2()'s structs will continue to grow for a while... and I'd really > like to have some numbers on when copy_struct_from_user() becomes > costly or how costly it becomes.) How long it takes? It should be basically the same, the costs should be mostly in switching memory protections, etc. I wouldn't imagine how many bytes being copied would matter much here, given the sub-page sizes. > > Ah yeah, I like this because of what you mention below: it's forward > > compat too. (I'd just use the ioctl masks directly...) > > > > switch (cmd & ~(_IOC_SIZEMASK | _IOC_DIRMASK)) > > > > > return seccomp_notify_addfd(filter, buf, _IOC_SIZE(cmd)); > > > > I really like that this ends up having the same construction as a > > standard EA syscall: the size is part of the syscall arguments. > > This is basically what I had proposed in my previous mail, right? I guess I missed it! Well, then I think we're all in agreement? :) -- Kees Cook
