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? :)