linux-kernel - Re: [PATCH v2] prctl: Add PR_GET

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 4 Apr 2023 12:43:55 -0700
From:   Andrew Morton <akpm@...ux-foundation.org>
To:     Josh Triplett <josh@...htriplett.org>
Cc:     linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] prctl: Add PR_GET_AUXV to copy auxv to userspace

On Tue, 4 Apr 2023 21:31:48 +0900 Josh Triplett <josh@...htriplett.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;