musl 1.1.0 released

musl 1.1.0 released

[Rich Felker]

New features include support for RELRO protection in dynamic linker,
VDSO acceleration for clock functions on x86_64, and improvements to
malloc that avoid early allocation failures specific to PIE binaries.
Several important bugs have been fixed, including searches past the
end of the buffer in memmem and multiple bugs in printf floating point
formatting, one of which may be able to trigger a buffer overflow
under certain conditions. Some bugs specific to the mips, microblaze,
and x32 ports have also been fixed.

http://www.musl-libc.org/releases/musl-1.1.0.tar.gz

Re: musl 1.1.0 released

[u-igbb]

On Wed, Apr 16, 2014 at 04:41:02AM -0400, Rich Felker wrote:
> New features include support for RELRO protection in dynamic linker,
> VDSO acceleration for clock functions on x86_64, and improvements to
> malloc that avoid early allocation failures specific to PIE binaries.

Nice work, thanks!

Any plans for accepting --library-path and --preload ?

For the record, I am depending on these since before musl and now with
musl. Any other approach to achieve flexible runtime binding between
binaries and libraries brings unfortunately extra constraints. Those
constraints (e.g. on the relative placement of binaries and libraries)
are too limiting and/or inconvenient to be practical in our environment.

Regards,
Rune

> Several important bugs have been fixed, including searches past the
> end of the buffer in memmem and multiple bugs in printf floating point
> formatting, one of which may be able to trigger a buffer overflow
> under certain conditions. Some bugs specific to the mips, microblaze,
> and x32 ports have also been fixed.
> 
> http://www.musl-libc.org/releases/musl-1.1.0.tar.gz

Re: musl 1.1.0 released

[Rich Felker]

On Wed, Apr 16, 2014 at 12:47:59PM +0200, u-igbb@aetey.se wrote:
> On Wed, Apr 16, 2014 at 04:41:02AM -0400, Rich Felker wrote:
> > New features include support for RELRO protection in dynamic linker,
> > VDSO acceleration for clock functions on x86_64, and improvements to
> > malloc that avoid early allocation failures specific to PIE binaries.
> 
> Nice work, thanks!
> 
> Any plans for accepting --library-path and --preload ?

Sorry, I meant to finish reviewing and address these in the 1.1.0
plans but I forgot about it. I'll look at them next.

Rich

Re: musl 1.1.0 released

[Rich Felker]

On Wed, Apr 16, 2014 at 12:47:59PM +0200, u-igbb@aetey.se wrote:
> On Wed, Apr 16, 2014 at 04:41:02AM -0400, Rich Felker wrote:
> > New features include support for RELRO protection in dynamic linker,
> > VDSO acceleration for clock functions on x86_64, and improvements to
> > malloc that avoid early allocation failures specific to PIE binaries.
> 
> Nice work, thanks!
> 
> Any plans for accepting --library-path and --preload ?
> 
> For the record, I am depending on these since before musl and now with
> musl. Any other approach to achieve flexible runtime binding between
> binaries and libraries brings unfortunately extra constraints. Those
> constraints (e.g. on the relative placement of binaries and libraries)
> are too limiting and/or inconvenient to be practical in our environment.

I'm committing a patch based loosely on yours that accepts more forms
(e.g. --preload=...) and one additional option (--list). Let me know
if it fails to meet your needs and I can improve it.

Rich

--library-path and friends (was: [musl] musl 1.1.0 released)

[u-igbb]

On Wed, Apr 16, 2014 at 12:53:52PM -0400, Rich Felker wrote:
> I'm committing a patch based loosely on yours that accepts more forms
> (e.g. --preload=...) and one additional option (--list). Let me know
> if it fails to meet your needs and I can improve it.

Without having looked at the code yet:

1. This is quite certainly just fine.

My needs are very basic, as long as it accepts "--library-path <somepath>"
which fully overrides LD_LIBRARY_PATH (not resetting it of course) and
--preload with a corresponding semantics, then I am in business and happy.

 --list is welcome!

2. Not every feature is certainly for good :)

Frankly I do not see any need for the '=' syntax extention, it probably
costs some extra byte[s] but more importantly once introduced you will
have to keep the extra possibility. I do not think (didn't check for a
while though) that either glibc or uclibc accept the '=' form.
A difference between the acceptable syntax variations in different
libraries would quite certainly confuse some people. These options imho
are expected to be used mostly in scripts (I never type "--library-path"
on a command line :) so keeping the syntax as uniform as possible will
help reusability and make the usage of the feature less error prone.

But this "as narrowly defined interface as sufficient" is just a
suggestion. Of course a richer inteface (the '=') will not influence
my usage in any way.

3. Why I care about "reusability" between libraries:

A "homogenous" c-library base (as of versions and/or implementations)
for all applications is unthinkable here. We have no limitations
on which versions of which applications compiled with which options
and linked against which versions of which libraries (compiled with
which options and so on) can be run. Any of them or many
simultaneously on the same computer are run as needed, easily.

Musl fits there very well, among others due to its stable ABI, but
the whole picture can probably never become "musl-only" just because
we avoid placing arbitrary constraints. (If an application for some
reason does need uclibc or glibc or something else, it will be given the
opportunity.) To make all of this work depends among others on the
libraries themselves not placing arbitrary constraints - nicely, musl
does a great job!

Thanks Rich.

Rune

Re: --library-path and friends (was: [musl] musl 1.1.0 released)

[Rich Felker]

On Thu, Apr 17, 2014 at 10:15:48AM +0200, u-igbb@aetey.se wrote:
> On Wed, Apr 16, 2014 at 12:53:52PM -0400, Rich Felker wrote:
> > I'm committing a patch based loosely on yours that accepts more forms
> > (e.g. --preload=...) and one additional option (--list). Let me know
> > if it fails to meet your needs and I can improve it.
> 
> Without having looked at the code yet:
> 
> 1. This is quite certainly just fine.
> 
> My needs are very basic, as long as it accepts "--library-path <somepath>"
> which fully overrides LD_LIBRARY_PATH (not resetting it of course) and
> --preload with a corresponding semantics, then I am in business and happy.
> 
>  --list is welcome!

Yes. And it makes it possible to implement ldd as a shell script using
ld-musl with --list rather than as a symlink to ld-musl. This is
probably better in that it works even if the desired argv[0] does not
get passed to ldd.

> 2. Not every feature is certainly for good :)
> 
> Frankly I do not see any need for the '=' syntax extention, it probably
> costs some extra byte[s] but more importantly once introduced you will
> have to keep the extra possibility. I do not think (didn't check for a

I'm not sure whether glibc's dynamic linker supports it, but the
processing of the form with --option=arg is part of the "standard"
getopt_long processing for long options, and I felt like it should be
supported here too for the sake of consistency if we're accepting long
options that look like getopt_long options. It's just one extra
(trivial) line of source anyway.

Rich

Re: --library-path and friends (was: [musl] musl 1.1.0 released)

[u-igbb]

On Fri, Apr 18, 2014 at 04:46:22PM -0400, Rich Felker wrote:
> > Frankly I do not see any need for the '=' syntax extention, it probably
> > costs some extra byte[s] but more importantly once introduced you will
> > have to keep the extra possibility. I do not think (didn't check for a
> 
> I'm not sure whether glibc's dynamic linker supports it, but the
> processing of the form with --option=arg is part of the "standard"
> getopt_long processing for long options, and I felt like it should be

As you correctly say getopt_long is a "standard" not a standard.

(AFAIK none of the other dynamic linkers support it, nor would the
getopt_long syntax convention give any real advantage in the expected
usage pattern)

> supported here too for the sake of consistency if we're accepting long
> options that look like getopt_long options. It's just one extra
> (trivial) line of source anyway.

Given that this costs a line which you will not be able to ever remove,
I'd wait with adding this at least until somebody asks for it.

I do not either like the extra resulting bytes inside the loader which
I have to deliver everywhere the software will be run. These bytes will
take the disk space, the network capacity and the RAM at many places,
with the sole reason being to allow an additional (and unused) way to
spell the same thing.

This feature would also force everyone possibly reinterpreting
the loader command line in scripts to add the code for parsing '='
just to cope with somebody else possibly having been used the extra
"freedom of expression" (without having said anything different :)

That's why in my eyes '=' looks like an unnecessary and actually harmful
"feature pollution" (even though the harm is small, it is there).

Of course I am extremely happy with the _functionality_ being there now.
The syntax details are just details :) and the choice is yours.

Thanks Rich!

Rune