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

[Adrian Bunk]

On Tue, Jan 11, 2005 at 06:12:46PM -0800, Barry K. Nathan wrote:
>...
> > 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.

uselib() is only one of the zillion places in the Linux kernel where 
security vulnerabilities can occur. OK, now one was found there, but
is this enough for changing the status quo if the zillion other places
with possible vulnerabilities are still present and will stay?
If a vendor chooses to diverge from the ftp.kernel.org kernel in this
point, I don't see why this should cause any "evil" problems.

> > 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.
>...

A patch for one config option for all pre-libc6 system calls might be 
interesting if it allows to disable a serious amount of system calls and 
is well-tested to not break any libc6, libc5 or libc4 binaries.

> -Barry K. Nathan <barryn@xxxxxxxxx>

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

-
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/