linux-kernel - Re: [PATCH 1/2] 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:	Mon,  7 Jul 2008 02:31:51 -0700 (PDT)
From:	Roland McGrath <roland@...hat.com>
To:	Andreas Schwab <schwab@...e.de>
Cc:	benh@...nel.crashing.org, Nathan Lynch <ntl@...ox.com>,
	linuxppc-dev@...abs.org, Paul Mackerras <paulus@...ba.org>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/2] elf loader support for auxvec base platform string

> That will make it part of the kernel ABI, since the mapping depends on
> the running kernel, doesn't it?

Well, not the permanent ABI in the sense that AT_* et al are.  This
mapping must agree among all users sharing the same ld.so.cache file.
That is all.  So if you were to change the meaning of a bit that was
used before with a different string, then you could not have the
conflicting ld.so.conf.d files both installed at the same time
(ldconfig will complain and fail).  If you wanted to have two kernels
both installed that disagree on the string for a given bit, then you'd
have to switch the ld.so.conf.d files and re-run ldconfig when you
switch which kernel you're booting.

There are 32 bits free now.  One can anticipate that reassigning a bit
would come up only after these are exhausted.  With prudent use, this
will take a very long time to happen.  Then the oldest CPU type string
might be retired to reuse its bit.  It seems unlikely that there will
be a single installation (root directory) that really needs to have
installed both a kernel optimized for the oldest CPU model known and a
kernel optimized for the newest CPU model known.  If there is, we can
worry about it then.  

At any rate, the point remains that these bit assignments are not part
of any published userland ABI one has to think about in all the ways
that the real ABI implies.  There is nowhere that has to know them or
will ever consider them, except the kernel with the vDSO image built
inside and the ld.so.conf.d file that goes with it.

Thanks,
Roland
--
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/