Re: [PATCH] make uselib configurable (was Re: uselib() & 2.6.X?)

[Barry K. Nathan]

On Wed, Jan 12, 2005 at 12:59:07AM +0100, Andries Brouwer wrote:
> > +config SYS_USELIB
> > +	bool "sys_uselib syscall support (needed for old binaries)"
> > +	---help---
> > +	  Many old binaries (e.g. dynamically linked a.out binaries, and
> > +	  ELF binaries that are dynamically linked against libc5), require
> > +	  the sys_uselib syscall. However, on the typical Linux system, this
> > +	  code is just old cruft that no longer serves a purpose.
> > +
> > +	  If you are unsure, say "N" if you care more about security and
> > +	  trimming bloat, or say "Y" if you care more about compatibility
> > +	  with old software. (If you will answer "Y" or "M" to BINFMT_AOUT,
> > +	  below, you probably should answer "Y" here.)
> 
> s/sys_uselib/uselib/
> The system call is uselib().

Ok.

> Hmm - old cruft.. Why insult your users?
> I do not have source for Maple. And my xmaple binary works just fine.
> But it is a libc4 binary.

Err... I didn't see it as "insulting [my] users". That was not at all
what I intended. I'll have to rework that...

> You mean "on the typical recently installed Linux system,
> with nothing but the usual Linux utilities".

No, more like, "on the typical Linux system installed since 2000,
running additional 3rd-party software from no earlier than 2001", or
something vaguely like that.

> People always claim that Linux is good in preserving binary compatibility.
> Don't know how true that was, but introducing such config options doesnt
> help.

Binary compatibility is good to have, but it isn't everything in life.
*Optionally* breaking compatibility with certain types of old binaries
doesn't seem so bad to me. People who want binary compatibility can have
it, and people who don't need it can choose to not install the old code
on their systems.

> Let me also mutter about something else.
> In principle configuration options are evil. Nobody wants fifty thousand
> configuration options. But I see them multiply like ioctls.
> There should be a significant gain in having a config option.
> 
> Maybe some argue that there is a gain in security here. Perhaps.
> Or a gain in memory. It is negligible.
> I see mostly a loss.

It's probably the case that on millions (and growing) of Linux systems
out there, the one and only possible use of this syscall is as a
security threat. On these systems, with no need for libc4/5 binaries
(and no installed versions of these libraries anyway), there is **NO**
other redeeming use for this syscall.

If removal of this syscall isn't a config option, then the alternatives
are out-of-tree patches, forking 2.7 over this issue alone, or settling
for the status quo. A 3rd-party patch would increase vendor kernel
divergence again (which is also evil), and starting 2.7 just for this
would be overkill. And I'm not the only person who is not satisfied
with the current situation.

> There are more ancient system calls, like old_stat and oldolduname.
> Do we want separate options for each system call that is obsoleted?

A config option for each one would be a bit much, I'll agree. However,
I think having a single config option for the whole bunch would be a
good idea. At the time that I wrote this patch, I was thinking that the
rest of the old syscalls would be a second config option, but now that I
think about it, it makes more sense for it to just be one config option,
not two.

FWIW, my current patch does uselib() alone, because I figured that would
be less controversial than trying to do all of the old syscalls now.
Maybe I'll rethink that decision though.

Thank you for your feedback. It's quite helpful, and I greatly
appreciate it.

-Barry K. Nathan <barryn@xxxxxxxxx>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/