Re: High UID support for Linux

david parsons (o.r.c@p.e.l.l.p.o.r.t.l.a.n.d.o.r.u.s)
26 Nov 1998 22:34:33 -0800

In article <linux.kernel.73ke37$psf$1@palladium.transmeta.com>,
H. Peter Anvin <hpa@transmeta.com> wrote:
>Followup to: <73hjqd$h54@pell.pell.portland.or.us>
>By author: o.r.c@p.e.l.l.p.o.r.t.l.a.n.d.o.r.u.s (david parsons)
>In newsgroup: linux.dev.kernel
>>
>> >Not that easy... the datatypes themselves would have to change, which
>> >means the old binaries would be useless.
>>
>> I'm not so sure about that; elf compatability may be [1] a lost
>> cause, but since a.out uses jump tables, all I'd need to do is move
>> the entry points for the new library calls up past where the older
>> calls are. I'd guess it would bloat libc by 40 to 50k (ick) to
>> thread the new calls into the existing library, but it's still
>> a very small library.
>>
>
>But now you have completely changed the ABI.

But I haven't. Remember it's all jump tables in a.out land [1], so
as long as you don't run off the allocated address space, you take
the old entry points

+-----+
|16bit|
| . |
| . |
| . |
+-----+

add the new entry points at the end

+-----+
| . |
| . |
+-----+

and make the libc .sa point at these new and improved ones, while
leaving the old entry points lying around for legacy code to use
(or blow up on, depending on what you prefer to have code that
depends on 16-bit UIDs doing in a 32-bit UID world. I'd be tempted
to just make the old entry points die if you do anything other than
getuid() because chopping precision off seems like a recipe for all
sorts of hilarious security breaches, but that may be unduely
paranoid on my part.

Though I'm not really sure what the a.out ld.so will do when
confronted with trying to run a libc+32bit uid application on a
libc-avec-32bit uid libc. I suspect it would simply smile sweetly
and attempt to run the application, with the expected core dump
when it tried to jump off into never-never land. The silver lining
about being the only Linux distribution that is a.out, though, is
that it's not very likely that anyone else will be carefully
lugging around their copies of libc 4.5.27 for Mastodon
administration tools to trip over.

[1: At least this is my understanding from trying to tweak the DLL
tools to work with egcs and other modern compilers. I'm sure
that people will rush to correct me if I'm missing several vital
points here.]

>> [2: libc 4.8.0 is 412 blocks long; if glibc is clocking in at
>> that size range, please let me know.]
>
>a.out glibc???

I'd certainly prefer an a.out glibc, so I could have a stable system
that won't be damaged when users update their all-elf libraries
incorrectly and thus convert userspace into an electronic train
wreck.

____
david parsons \bi/ ObKernel: I certainly hope that a.out support won't
\/ be removed from the kernel any time soon, since it's
the only way I can guarantee backwards compatability.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/