Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Tue, 4 Apr 2023 12:43:55 -0700
From:   Andrew Morton <akpm@linux-foundation.org>
To:     Josh Triplett <josh@joshtriplett.org>
Cc:     linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] prctl: Add PR_GET_AUXV to copy auxv to userspace
Message-Id: <20230404124355.3efa7a201d2aa9896dc6353e@linux-foundation.org>
In-Reply-To: <d81864a7f7f43bca6afa2a09fc2e850e4050ab42.1680611394.git.josh@joshtriplett.org>
References: <d81864a7f7f43bca6afa2a09fc2e850e4050ab42.1680611394.git.josh@joshtriplett.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Precedence: bulk

On Tue, 4 Apr 2023 21:31:48 +0900 Josh Triplett <josh@joshtriplett.org> wrote:

> If a library wants to get information from auxv (for instance,
> AT_HWCAP/AT_HWCAP2), it has a few options, none of them perfectly
> reliable or ideal:
> 
> - Be main or the pre-main startup code, and grub through the stack above
>   main. Doesn't work for a library.
> - Call libc getauxval. Not ideal for libraries that are trying to be
>   libc-independent and/or don't otherwise require anything from other
>   libraries.
> - Open and read /proc/self/auxv. Doesn't work for libraries that may run
>   in arbitrarily constrained environments that may not have /proc
>   mounted (e.g. libraries that might be used by an init program or a
>   container setup tool).
> - Assume you're on the main thread and still on the original stack, and
>   try to walk the stack upwards, hoping to find auxv. Extremely bad
>   idea.
> - Ask the caller to pass auxv in for you. Not ideal for a user-friendly
>   library, and then your caller may have the same problem.

How does glibc's getauxval() do its thing?  Why can't glibc-independent
code do the same thing?

> Add a prctl that copies current->mm->saved_auxv to a userspace buffer.
> 
> ...
>
> --- a/include/uapi/linux/prctl.h
> +++ b/include/uapi/linux/prctl.h
> @@ -290,4 +290,6 @@ struct prctl_mm_map {
>  #define PR_SET_VMA		0x53564d41
>  # define PR_SET_VMA_ANON_NAME		0
>  
> +#define PR_GET_AUXV		0x41555856

How was this constant arrived at?

> --- a/kernel/sys.c
> +++ b/kernel/sys.c
> @@ -2377,6 +2377,16 @@ static inline int prctl_get_mdwe(unsigned long arg2, unsigned long arg3,
>  		PR_MDWE_REFUSE_EXEC_GAIN : 0;
>  }
>  
> +static int prctl_get_auxv(void __user *addr, unsigned long len)
> +{
> +	struct mm_struct *mm = current->mm;
> +	unsigned long size = min_t(unsigned long, sizeof(mm->saved_auxv), len);
> +
> +	if (size && copy_to_user(addr, mm->saved_auxv, size))
> +		return -EFAULT;
> +	return sizeof(mm->saved_auxv);
> +}

The type choices are unpleasing.  Maybe make `len' a size_t and make
the function return a size_t?  That way prctl_get_auxv() will be much
nicer, but the caller less so.

>  SYSCALL_DEFINE5(prctl, int, option, unsigned long, arg2, unsigned long, arg3,
>  		unsigned long, arg4, unsigned long, arg5)
>  {
> @@ -2661,6 +2671,11 @@ SYSCALL_DEFINE5(prctl, int, option, unsigned long, arg2, unsigned long, arg3,
>  	case PR_SET_VMA:
>  		error = prctl_set_vma(arg2, arg3, arg4, arg5);
>  		break;
> +	case PR_GET_AUXV:
> +		if (arg4 || arg5)
> +			return -EINVAL;
> +		error = prctl_get_auxv((void __user *)arg2, arg3);
> +		break;
>  	default:
>  		error = -EINVAL;
>  		break;