On Sat, Nov 19, 2022 at 01:09:27PM +0100, Jason A. Donenfeld wrote:
> +SYSCALL_DEFINE3(vgetrandom_alloc, unsigned long __user *, num,
> + unsigned long __user *, size_per_each, unsigned int, flags)
> +{
> + unsigned long alloc_size;
> + unsigned long num_states;
> + unsigned long pages_addr;
> + int ret;
> +
> + if (flags)
> + return -EINVAL;
> +
> + if (get_user(num_states, num))
> + return -EFAULT;
> +
> + alloc_size = size_mul(num_states, sizeof(struct vgetrandom_state));
> + if (alloc_size == SIZE_MAX)
> + return -EOVERFLOW;
> + alloc_size = roundup(alloc_size, PAGE_SIZE);
Small detail: the roundup to PAGE_SIZE can make alloc_size overflow to 0.
Also, 'roundup(alloc_size, PAGE_SIZE)' could be 'PAGE_ALIGN(alloc_size)'.
> + pages_addr = vm_mmap(NULL, 0, alloc_size, PROT_READ | PROT_WRITE,
> + MAP_PRIVATE | MAP_ANONYMOUS | MAP_LOCKED, 0);
> + if (IS_ERR_VALUE(pages_addr))
> + return pages_addr;
This will only succeed if the userspace process has permission to mlock pages,
i.e. if there is space available in RLIMIT_MEMLOCK or if process has
CAP_IPC_LOCK. I suppose this is working as intended, as this syscall can be
used to try to allocate and mlock arbitrary amounts of memory.
I wonder if this permission check will cause problems. Maybe there could be a
way to relax it for just one page per task? I don't know how that would work,
though, especially when the planned usage involves userspace allocating a single
pool of these contexts per process that get handed out to threads.
- Eric
