linux-kernel - Re: [PATCH v3] elf loader support for auxvec base platform string

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:	Fri, 18 Jul 2008 13:31:29 -0700
From:	John Reiser <jreiser@...Wagon.com>
To:	Nathan Lynch <ntl@...ox.com>
CC:	Andrew Morton <akpm@...ux-foundation.org>,
	benh@...nel.crashing.org, torvalds@...ux-foundation.org,
	linuxppc-dev@...abs.org, linux-kernel@...r.kernel.org,
	roland@...hat.com
Subject: Re: [PATCH v3] elf loader support for auxvec base platform string

Nathan Lynch wrote:

> +#define AT_EXECFN  31	/* filename of program */
> 
> How did you arrive at 31 for the value of AT_EXECFN?  I haven't been
> able to find out how AT_* values are "allocated", or what the reason
> is for the gap between AT_SECURE and AT_SYSINFO.

The numbers are chosen by experience, taste, and fiat.
Hopefully new choices do not conflict with existing ones,
but there is no formal "issuing authority."
In history the auxiliary vector has been not well standardized
and many times has been hidden from view of applications, although some
SysV-based systems have made it visible as a fourth argument to main().
Linux has /proc/pid/auxv, although the implementation suffers
from being exposed to overwriting by the user.  From long experience
at virtualization in user mode, I favor better access, more use,
and better understanding of what the auxiliary vector provides.

AT_SYSINFO at 32 was chosen to avoid conflicts with [0,31]
partly on the theory that the first 32 might be considered
to be reserved for use across all UNIX-like systems,
while AT_SYSINFO definitely was Linux-specific.
I chose AT_EXECFN at 31 because I considered the concept
to be applicable to any system having execve(), even if AT_EXECFN
is not universally implemented.  I had not seen any new tags
below 32 in a long time.  The concept of AT_EXECFN allows
a nice interface for a virtualizer. The somewhat-related
AT_EXECFD already exists below 32.

Elsewhere, I've staked out use of a new AT_WINE_PRELOAD_INFO
at 30.  Avoid that one, please. :-)

-- 
John Reiser, jreiser@...Wagon.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/