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]

Message-Id: <20080708003127.6D3B9154244@magilla.localdomain>
Date:	Mon,  7 Jul 2008 17:31:27 -0700 (PDT)
From:	Roland McGrath <roland@...hat.com>
To:	benh@...nel.crashing.org
Cc:	Andreas Schwab <schwab@...e.de>, 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

> > The kernel does not have to come from the same place as the root
> > filesystem.  You may want to run a new kernel with an old filesystem, or
> > vice-versa.

Well, it's not like these bits are really going to change in practice.  My
point was just that this is a far "softer" ABI than the general kernel-user
contract.  Sorry if my being precise about things gives you indigestion.

> I agree, I'm pretty dubious here...

Dubious about whether the dsocaps bit assignments are "part of the ABI"?
Fine.  Let's talk again when you've used up 32 bits and want to figure out
what to do next.

Dubious about whether dsocaps is the right thing to do?  I think you are
overlooking what the actual kernel-user compatibility reality is here.

Firstly, what is the "risk" in the "gone wrong" case?  The risk is that a
DSO load via ld.so.cache will overlook a /lib/power99/foo.so match and get
a /lib/foo.so match instead because ldconfig doesn't know about "power99".
If foo.so wasn't in ld.so.cache at all, there is no problem.
If you used LD_LIBRARY_PATH, there is no problem.
If you used dlopen with an explicit file name (has /), there is no problem.

What happens if you boot a kernel that uses dsocaps with the new string
"power99", but you are missing the ld.so.conf.d file to match your kernel?
Then a DSO load via ld.so.cache will overlook "power99" matches.

How do you fix it?
Install the right (tiny text) file, and run ldconfig.

What happens now if you are using a new kernel that supplies a new string
"power99" in AT_PLATFORM or another auxv element used the same way, but
with an old root filesystem (say one including any glibc that exists today)?
Then a DSO load via ld.so.cache will overlook "power99" matches.

How do you fix it?
You add a bit assignment in the glibc sources, recompile glibc,
install a new whole glibc package.  (Conceivably if you are extremely
careful you can manage to redo an otherwise completely identical
build to the glibc on your old system and replace only ld{64,}.so.1
and ldconfig.)  Then run the new ldconfig.

In short, if you use a root filesystem from before kernels started using
the new string, then you will degenerate to default-platform library
matches from loads via ld.so.cache (i.e. /lib/foo.so, not /lib/somecpu/foo.so).
If you want to do better than that for this case, it's intractable using
AT_PLATFORM, and simple using dsocaps (probably simpler than booting a
special kernel was).

I haven't figured out what in this old-vs-new picture you think AT_PLATFORM
or something else like it would ever buy you.

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/