Bug#972510: glibc: Please ignore misc/tst-sbrk and/or misc/tst-sbrk-pie on all archs

2020-10-23 Thread Florian Weimer
* Aurelien Jarno:

> brk/sbrk is definitely something deprecated. But it is still part of the
> API (especially for old architectures) and still used by software like
> jemalloc, gcl or libgc. This is therefore important to keep this feature
> in a good shape.
>
> It's also used by many less important packages, often just to print a
> backtrace.
>
> If someone has spoons it might be worth opening bugs again those
> package, so that they stop using brk/sbrk.

glibc malloc also uses sbrk, and has some glitches in corner cases
when it has to switch from sbrk to mmap for the main arena.

I think it is worth investigating *why* sbrk fails.  Usually that is
due to an obstructing mapping caused by problematic address space
layouts.  With ASLR, such failures can essentially appear to be
random.



Bug#969645: glibc: deferred error : (error "Deferred process exited abnormally:

2020-09-06 Thread Florian Weimer
* Aurelien DESBRIERES:

> This is emacs and jedi-mode and much more elisp stuff to works with
> emacs as python3 ide.
>
> Please update this glibc it seems to be outdated!

That's simply not going to happen for the buster release.

You will have to change the way you set up your pip environment.



Bug#969645: glibc: deferred error : (error "Deferred process exited abnormally:

2020-09-06 Thread Florian Weimer
* aurelien desbrieres:

> *** Reporter, please consider answering these questions, where appropriate ***
>
>* What led up to the situation?
>try to use jedi-mode on emacs
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
>M-x jedi:install-server
>* What was the outcome of this action?
>deferred error : (error "Deferred process exited abnormally:
>   command: /home/aurelien/.emacs.d/.python-environments/default/bin/pip
>   exit status: exit 1
>   event: exited abnormally with code 1
>   buffer contents: 
> \"/home/aurelien/.emacs.d/.python-environments/default/bin/python3: 
> /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.29' not found (required by 
> /home/aurelien/.emacs.d/.python-e\
> nvironments/default/bin/python3)
> \"")

Have you copied the pip environment from another system?  You need to
regenerate on this host.



Bug#969618: getopt: optarg is NULL outside of loop

2020-09-06 Thread Florian Weimer
* John Scott:

> #define _POSIX_C_SOURCE 200809L
> #include 
> #include 
> #include 
> #include 
> int main(int argc, char *argv[]) {
>   int opt;
>   while((opt = getopt(argc, argv, "a:")) != -1) {}
>   assert(optarg != NULL);
> }
>
> If this is invoked as './a.out -afoo', the inner assertion will
> the last assertion will fail with glibc.

POSIX leaves it unspecified if optarg is changed if getopt returns -1.
Only optind must be left unchanged.  I do not think this is a glibc
bug (or a musl bug).



Bug#967938: libc6: systemd-sysusers SEGV due to glibc bug in fgetgsent

2020-08-06 Thread Florian Weimer
* Aurelien Jarno:

> On 2020-08-06 06:08, Jinpu Wang wrote:
>> Hi Florian,
>> 
>> On Wed, Aug 5, 2020 at 6:44 PM Florian Weimer  wrote:
>> >
>> > * Jinpu Wang:
>> >
>> > > Dear Maintainer:
>> > >
>> > > Sorry, add some missing information below:
>> > >
>> > > After update to Buster, the systemd-sysusers are segfaulting every time.
>> > > After search around, I found following bugreport in glibc
>> > > https://sourceware.org/legacy-ml/libc-alpha/2016-06/msg01015.html
>> > >
>> > > I backported to the fix to 2.28-10, it fixed the problem.
>> > >
>> > > glibc upstream have a different fix for it in 2.32, see
>> > >  https://sourceware.org/bugzilla/show_bug.cgi?id=20338
>> > >
>> > > I think it's still easier to backport the fix in msg01015.html to 2.28 
>> > > version,
>> > > patch attached in the initial report.
>> >
>> > The patch from 2016 is incomplete because it does not seek back to the
>> > original file position, so the next call of fgetsgent_r skips over the
>> > entry that could not be fully parsed.
>> Thanks for quick response,  can you provide a minimum bugfix, which
>> can be easily backported to old version like 2.28?
>
> I think we do not want to diverge from the upstream fix, even if it is a
> bit more work to backport. We first need to fix it in bullseye/sid and
> then we can try to get this in the next buster stable release.

I can backport it to upstream release branches, all the way to version
2.28.  Would that help?

I plan to add local copies of the new functions, so that the
GLIBC_PRIVATE ABI remains unchanged.

But I have other commitments, so that may not happen until
September-ish.

>> as you also make the bug 20338 as a security hole.
>
> It is marked as "security-", so it is *not* considered as a security
> issue (as the content of this file is trusted).

That's right.



Bug#967938: libc6: systemd-sysusers SEGV due to glibc bug in fgetgsent

2020-08-05 Thread Florian Weimer
* Jinpu Wang:

> Dear Maintainer:
>
> Sorry, add some missing information below:
>
> After update to Buster, the systemd-sysusers are segfaulting every time.
> After search around, I found following bugreport in glibc
> https://sourceware.org/legacy-ml/libc-alpha/2016-06/msg01015.html
>
> I backported to the fix to 2.28-10, it fixed the problem.
>
> glibc upstream have a different fix for it in 2.32, see
>  https://sourceware.org/bugzilla/show_bug.cgi?id=20338
>
> I think it's still easier to backport the fix in msg01015.html to 2.28 
> version,
> patch attached in the initial report.

The patch from 2016 is incomplete because it does not seek back to the
original file position, so the next call of fgetsgent_r skips over the
entry that could not be fully parsed.



Re: Arch qualification for buster: call for DSA, Security, toolchain concerns

2020-08-04 Thread Florian Weimer
* Florian Weimer:

>>  * Concern for mips, mips64el, mipsel and ppc64el: no upstream support
>>in GCC
>>(Raised by the GCC maintainer; carried over from stretch)
>
> I'm surprised to read this.  ppc64el features prominently in the
> toolchain work I do (though I personally do not work on the GCC side).

The ppc64le situation has been clarified.  It's now listed explicitly
as a primary architecture, as powerpc64le-unknown-linux-gnu:

  <https://gcc.gnu.org/gcc-11/criteria.html>

This has always been the intent, but I can understand that
distributions view powerpc64le-unknown-linux-gnu and
powerpc64-unknown-linux-gnu quite very different things.



Re: Arch qualification for buster: call for DSA, Security, toolchain concerns

2020-07-09 Thread Florian Weimer
* Paul Gevers:

>  * Concern for armel and armhf: only secondary upstream support in GCC
>(Raised by the GCC maintainer; carried over from stretch and buster)

glibc upstream lately has trouble finding qualified persons to
implement security fixes for the 32-bit Arm architecture.

>  * Concern for mips, mips64el, mipsel and ppc64el: no upstream support
>in GCC; Debian carries patches in binutils and GCC that haven't been
>integrated upstream even after a long time.
>(Raised by the GCC maintainer; carried over from stretch and buster)

I think I said this the last time, but the claim that there is no GCC
upstream support for ppc64le in GCC or binutils does not appear to be
grounded in fact. 8-/



Re: [RFC PATCH v4 1/2] configure: Remove --enable-obsolete-nsl

2020-06-30 Thread Florian Weimer
* Petr Vorel:

>> nss_compat no longer depends on libnsl in current glibc.  It can be used
>> without NIS, and some users do that.  I don't think your patch changes
>> this.

> Interesting. I guess adding this would be worth then:
> libnss_compat no longer depends on libnsl and can be used without NIS.

We made this change a while back, in glibc 2.27, when the sources were
moved to nss/nss_compat (from nis/nss_compat).  So this isn't something
new.

Thanks,
Florian



Re: [RFC PATCH v4 1/2] configure: Remove --enable-obsolete-nsl

2020-06-30 Thread Florian Weimer
* Petr Vorel:

> Hi Florian,
>
> thank you for your review. I'll have time to send next version in second
> half of July.

If we merge new ports for glibc 2.32, it would be nice not include
sunrpc in them.  We'll figure something out.

>> > diff --git a/grp/initgroups.c b/grp/initgroups.c
>> > index f4c4e986e9..0c17141117 100644
>> > --- a/grp/initgroups.c
>> > +++ b/grp/initgroups.c
>> > @@ -31,12 +31,6 @@
>> >  #include "../nscd/nscd-client.h"
>> >  #include "../nscd/nscd_proto.h"
>
>> > -#ifdef LINK_OBSOLETE_NSL
>> > -# define DEFAULT_CONFIG "compat [NOTFOUND=return] files"
>> > -#else
>> > -# define DEFAULT_CONFIG "files"
>> > -#endif
>> > -
>
>> That looks a bit like a pre-existing bug—we do have nss_compat even
>> without libnsl.  But the change itself looks okay.

> Hm, I'll have look into it after this patchset is finished, but not sure
> if I'm able to fix this.

Sorry, no change to the patch is required.  Removing this is fine.  We
shouldn't have had a default that depends on LINK_OBSOLETE_NSL.

> Hm, libnss_compat is not built (now libnsl is only built as shared
> library, for platforms where it was supported), so what exactly would
> you put here?

nss_compat no longer depends on libnsl in current glibc.  It can be used
without NIS, and some users do that.  I don't think your patch changes
this.

Thanks,
Florian



Re: [RFC PATCH v4 1/2] configure: Remove --enable-obsolete-nsl

2020-06-24 Thread Florian Weimer
* Petr Vorel:

> diff --git a/NEWS b/NEWS
> index a660fc59a8..cfaf50c816 100644
> --- a/NEWS
> +++ b/NEWS
> @@ -33,6 +33,14 @@ Major new features:
>  
>  Deprecated and removed features, and other changes affecting compatibility:
>  
> +* Remove configure option --enable-obsolete-nsl. libnsl is only built as 
> shared
> +  library for backward compatibility and the NSS modules libnss_compat,
> +  libnss_nis and libnss_nisplus are not built at all, libnsl's headers aren't
> +  installed. This compatibility is kept only for architectures and ABIs that
> +  have been added in or before version 2.28. Replacement implementations 
> based
> +  on TI-RPC, which additionally support IPv6, are available from
> +  .
> +

Please add two spaces after sentence-ending periods.  And wrap the lines
a bit earlier (column 72 or so).

> diff --git a/grp/initgroups.c b/grp/initgroups.c
> index f4c4e986e9..0c17141117 100644
> --- a/grp/initgroups.c
> +++ b/grp/initgroups.c
> @@ -31,12 +31,6 @@
>  #include "../nscd/nscd-client.h"
>  #include "../nscd/nscd_proto.h"
>  
> -#ifdef LINK_OBSOLETE_NSL
> -# define DEFAULT_CONFIG "compat [NOTFOUND=return] files"
> -#else
> -# define DEFAULT_CONFIG "files"
> -#endif
> -

That looks a bit like a pre-existing bug—we do have nss_compat even
without libnsl.  But the change itself looks okay.
 
> diff --git a/manual/nss.texi b/manual/nss.texi
> index 821469a78a..7cb307246a 100644
> --- a/manual/nss.texi
> +++ b/manual/nss.texi
> @@ -328,17 +328,11 @@ For the @code{hosts} and @code{networks} databases the 
> default value is
>  the DNS service not to be available but if it is available the answer it
>  returns is definitive.
>  
> -The @code{passwd}, @code{group}, and @code{shadow} databases are
> +The @code{passwd}, @code{group}, and @code{shadow} databases was
>  traditionally handled in a special way.  The appropriate files in the
> -@file{/etc} directory are read but if an entry with a name starting
> -with a @code{+} character is found NIS is used.  This kind of lookup
> -remains possible if @theglibc{} was configured with the
> -@code{--enable-obsolete-nsl} option and the special lookup service
> -@code{compat} is used.  If @theglibc{} was configured with the
> -@code{--enable-obsolete-nsl} option the default value for the three
> -databases above is @code{compat [NOTFOUND=return] files}.  If the
> -@code{--enable-obsolete-nsl} option was not used the default value
> -for the services is @code{files}.
> +@file{/etc} directory were read but if an entry with a name starting
> +with a @code{+} character was found NIS was used.  This kind of lookup
> +was removed and now the default value for the services is @code{files}.

I wonder if it makes sense to reference nss_compat here?

Thanks,
Florian



Bug#963508: /lib/ld-linux.so.2: LD_PRELOAD breaks with plain filename [and 1 more messages]

2020-06-24 Thread Florian Weimer
* Aurelien Jarno:

>> This doesn't seem correct to me.  Is there any documentation giving a
>> rationale for this ?  Is there a way to change this locally ?
>
> I do not know enough about apparmor and its threat model to know if it
> should be considered or not. From the glibc point of view, nothing can
> be really done, it just obeys the AT_SECURE flag passed by the kernel.
>
> Now looking at apparmor.d(5), it seems it *might* be controlled by the
> change_profile option with the safe and unsafe mode. But I don't speak
> apparmor fluently enough to actually know how to introduce that option
> in a profile.

I think LSMs can nowadays also express security transitions that trust
the execution environment, that is, that they add more restrictions
instead of increasing privileges.  I believe we use this with SELinux,
so that these transitions to do not cause AT_SECURE to be set.  Maybe
this is something that apparmor could do as well?

Thanks,
Florian



Re: [RFC PATCH v2 0/2] Remove --enable-obsolete-nsl --enable-obsolete-rpc

2020-06-05 Thread Florian Weimer
* Petr Vorel:

>> I'm still having issues with elf/tst-ldconfig-ld_so_conf-update when
>> running with both commits (it's ok when running only first commit).
>
> OK, I noticed core dump (can be reproduced):
> systemd-coredump[26018]: Process 26016 (ld-linux-x86-64) of user 1000 dumped 
> core.
>
>PID: 26016 (ld-linux-x86-64)
>UID: 1000 (foo)
>GID: 100 (users)
> Signal: 6 (ABRT)
>  Timestamp: Fri 2020-06-05 18:41:54 CEST (16min ago)
>   Command Line: 
> /home/foo/build/glibc/remove-rpc.v2.second-commit.2/elf/ld-linux-x86-64.so.2 
> --library-path 
> /home/foo/build/glibc/remove-rpc.v2.second-commit.2:/home/foo/build/glibc/remove-rpc.v2.second-commit.2/math:/home/foo/build/glibc/remove-rpc.v2.second-commit.2/elf:/home/foo/build/glibc/remove-rpc.v2.second-commit.2/dlfcn:/home/foo/build/glibc/remove-rpc.v2.second-commit.2/nss:/home/foo/build/glibc/remove-rpc.v2.second-commit.2/nis:/home/foo/build/glibc/remove-rpc.v2.second-commit.2/rt:/home/foo/build/glibc/remove-rpc.v2.second-commit.2/resolv:/home/foo/build/glibc/remove-rpc.v2.second-commit.2/mathvec:/home/foo/build/glibc/remove-rpc.v2.second-commit.2/support:/home/foo/build/glibc/remove-rpc.v2.second-commit.2/crypt:/home/foo/build/glibc/remove-rpc.v2.second-commit.2/nptl
>  /home/foo/build/glibc/remove-rpc.v2.second-commit.2/debug/tst-ssp-1
> Executable: /home/foo/build/glibc/remove-rpc.v2.second-commit.2/elf/ld.so
>  Control Group: /user.slice/user-1000.slice/session-1.scope
>   Unit: session-1.scope
>  Slice: user-1000.slice
>Session: 1
>  Owner UID: 1000 (foo)
>Boot ID: bfef12e3ca2046009a97d35fb89674bc
> Machine ID: 66e50c6d8dd0edc674b23b51586326ca
>   Hostname: dell5510
>Storage: none
>Message: Process 26016 (ld-linux-x86-64) of user 1000 dumped core.
> Coredump entry has no core attached (neither internally in the journal nor 
> externally on disk).

This seems unrelated.  I think systemd-coredump ignores ulimit -c 0
(which we perform programatically in the test skeleton), to cover cases
like this where the process is expected to abort.  So you get a few
spurious reports like this one.

Thanks,
Florian



Bug#956418: src:glibc: Please provide optimized builds for ARMv8.1

2020-04-30 Thread Florian Weimer
* Florian Weimer:

> I raised the matter of compiler defaults on the GCC list:
>
>   <https://gcc.gnu.org/pipermail/gcc/2020-April/232261.html>

The link is now: <https://gcc.gnu.org/pipermail/gcc/2020-April/000491.html>



Bug#956418: src:glibc: Please provide optimized builds for ARMv8.1

2020-04-29 Thread Florian Weimer
I raised the matter of compiler defaults on the GCC list:

  

Thanks,
Florian



Bug#956418: src:glibc: Please provide optimized builds for ARMv8.1

2020-04-22 Thread Florian Weimer
* Noah Meyerhans:

> On Sun, Apr 12, 2020 at 12:18:35PM +0200, Aurelien Jarno wrote:
>> > Significant performance impact has also been observed in less contrived
>> > cases (MariaDB and Postgres), but I don't have a repro to share.
>> 
>> But indeed what counts is number on real workloads. It would be nice to
>> get numbers when those software are run against a rebuilt glibc. As
>> those software are using a lot of atomics directly, it would be also
>> interesting to have numbers with those software also rebuilt to use
>> those new instructions.
>
> Agreed.  I don't have specific examples of real world impact at the
> moment.  AIUI, the most significant impact comes in the usage of atomics
> in pthread_mutex_lock().  When there are multiple threads contending for
> a lock, one thread will (approximately) always obtain the lock, while
> the others will starve.  With atomics support in place, the probability
> of obtaining the lock is roughly evenly distributed among all the
> threads.  So any workload in which multiple threads may contend for a
> lock should be a candidate to demonstrate this problem in the real
> world.

Does this behavior affect just one implementation with LSE, or also
implementations without LSE?

If the latter, we might need a different mutex implementation for
AArch64. 8-(



Bug#956418: src:glibc: Please provide optimized builds for ARMv8.1

2020-04-11 Thread Florian Weimer
* Noah Meyerhans:

> On Sat, Apr 11, 2020 at 09:14:11PM +0200, Florian Weimer wrote:
>> > At least if I'm reading the code right (which I may very well not be
>> > doing, being generally unfamiliar with gcc internals), -mtune=generic
>> > enables the equivalent of ARMv8 support:
>> >
>> > https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/common/config/aarch64/aarch64-common.c;h=0bddcc8c3e9282a957c5479b4df7f68058093bab;hb=HEAD#l176
>> >
>> > https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/config/aarch64/aarch64-cores.def;h=ea9b98b4b0ad2a578755561bba5b6d5c56115994;hb=HEAD
>> >
>> > https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/config/aarch64/aarch64.h;h=8f08bad3562c4cbe8acdf5891e84f89d23ea6784;hb=HEAD#l226
>> 
>> Hmm.  I don't see anything that sets TARGET_OUTLINE_ATOMICS by
>> default.
>
> Only -moutline-atomics enables that.  Otherwise, unconditional support
> for atomics is enabled by TARGET_LSE, which itself is enabled by a
> number of options, e.g. -marmv8-a+lse, -marmv8.1-a, etc.
>
> See
> https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/config/aarch64/aarch64.c;h=4af562a81ea760891fac3cf7101b8bf887fe7a0d;hb=HEAD#l18961

Sorry, I have a feeling that we are discussing different matters.

I believe that ideally, Debian (and Fedora etc.) should follow
upstream GCC defaults.  I don't think we are in this state
(code_for_aarch64_compare_and_swap uses the atomics.md patterns to
call aarch64_split_compare_and_swap, as far as I can see).

Or put differently: If upstream doesn't want to default to
-moutline-atomics, why should Debian?



Bug#956418: src:glibc: Please provide optimized builds for ARMv8.1

2020-04-11 Thread Florian Weimer
* Noah Meyerhans:

> On Sat, Apr 11, 2020 at 08:44:29AM +0200, Florian Weimer wrote:
>> > Gcc provides two ways to enable support for these instructions at build
>> > time.  The simplest, and least disruptive, is to enable -moutline-atomics
>> > globally in the arm64 glibc build.
>> 
>> Shouldn't GCC do this by default, at least for -mtune=generic?
>
> Maybe.  Would you rather pursue that avenue first?

My hope is that GCC upstream defaults reflect current practices for
the architecture.  It doesn't make sense if every distribution ends up
patching in same GCC defaults which are not upstream.

Sure, there might be bare-metal targets which do not want this, but is
this really the primary audience nowadays?

> At least if I'm reading the code right (which I may very well not be
> doing, being generally unfamiliar with gcc internals), -mtune=generic
> enables the equivalent of ARMv8 support:
>
> https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/common/config/aarch64/aarch64-common.c;h=0bddcc8c3e9282a957c5479b4df7f68058093bab;hb=HEAD#l176
>
> https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/config/aarch64/aarch64-cores.def;h=ea9b98b4b0ad2a578755561bba5b6d5c56115994;hb=HEAD
>
> https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/config/aarch64/aarch64.h;h=8f08bad3562c4cbe8acdf5891e84f89d23ea6784;hb=HEAD#l226

Hmm.  I don't see anything that sets TARGET_OUTLINE_ATOMICS by
default.



Bug#956418: src:glibc: Please provide optimized builds for ARMv8.1

2020-04-11 Thread Florian Weimer
* Noah Meyerhans:

> Gcc provides two ways to enable support for these instructions at build
> time.  The simplest, and least disruptive, is to enable -moutline-atomics
> globally in the arm64 glibc build.

Shouldn't GCC do this by default, at least for -mtune=generic?



Bug#954715: glibc: FTBFS: tests failed: signal/tst-minsigstksz-1 signal/tst-minsigstksz-2

2020-03-22 Thread Florian Weimer
* Lucas Nussbaum:

> Source: glibc
> Version: 2.30-2
> Severity: serious
> Justification: FTBFS on amd64
> Tags: bullseye sid ftbfs
> Usertags: ftbfs-20200322 ftbfs-bullseye
>
> Hi,
>
> During a rebuild of all packages in sid, your package failed to build
> on amd64.

>> FAIL: signal/tst-minsigstksz-1
>> FAIL: signal/tst-minsigstksz-2

--
--
FAIL: signal/tst-minsigstksz-1
original exit status 1
Didn't expect signal from child: got `Segmentation fault'
--
--
FAIL: signal/tst-minsigstksz-2
original exit status 1
Incorrect signal from child: got `Segmentation fault', need `Aborted'


The build host has this CPU:

model name  : Intel(R) Xeon(R) Platinum 8175M CPU @ 2.50GHz

This CPU supports AVX-512, and the minimum signal stack size is not
large enough for the amount of data the kernel saves on the stack.

  



Bug#953083: __glibc_has_include macro needs to be restored until GCC is rebuilt

2020-03-13 Thread Florian Weimer
* Matthias Klose:

> ok, now removing that leads to:
>
> $ cat foo.c
> #include 
>
> $ gcc -c foo.c
> In file included from foo.c:1:
> /usr/include/limits.h:124:26: error: no include path in which to search for 
> limits.h
>   124 | # include_next 
>   |  ^
>
> wondering if other distros patch glibc for that ...

Other distributions install limits.h from GCC (in a directory under
/usr/lib/gcc), and that header is picked up first, before
/usr/include/limits.h.



Bug#953083: __glibc_has_include macro needs to be restored until GCC is rebuilt

2020-03-04 Thread Florian Weimer
* Matthias Klose:

> On 3/4/20 9:33 AM, Florian Weimer wrote:
>> * Matthias Klose:
>> 
>>> The __glibc_has_include macro needs to be restored until GCC is rebuilt. At
>>> least on s390x, you get a non-wrorking compiler, which at least cannot glibc
>>> anymore.  The macro is still referenced in the include-fixed directory.
>>>
>>> Seen with the 2.31 branch, but I see that this is also backported to 2.30.
>> 
>> This is a bug in the gcc package.  It must not run fixincludes, to
>> avoid producing mutually incompatible headers because only a subset of
>> them is rewritten.
>
> Is this something which should be done upstream?  Or just don't include any
> fixed header in the GCC packages?

Distributions should never run fixincludes for this reason.  This is a
hack for installing compilers as non-root on proprietary systems,
where you can't fix the headers.

Other distributions routinely backport compiler compatibility fixes
into glibc (even into stable releases), and I think this is the way it
has to be done.

> Anyway, either glibc or GCC has to be fixed to avoid a non-working compiler.

If I recall correctly, the header is broken anyway because linux is
rewritten into __linux__, due to a fixincludes bug.

It should be possible to hide the header by having a file with an
#include directive with an absolute path in a directory used during
the build.



Bug#767756: glibc: Consider providing a libc build compiled with -fno-omit-frame-pointer to help with profiling

2020-02-16 Thread Florian Weimer
* Aurelien Jarno:

>> I've been running into this myself a lot lately and wonder if
>> anything has happened regarding this since 2014, after all it's
>> been six years.

>> I'm surprised so few people seem to be taking interest in this
>> considering the amount of tools that rely on frame pointers for
>> performant stack traces, which has further increased with the
>> introduction of eBPF.
>
> I understand the need for -fno-omit-frame-pointer, however it has a
> performance impact, so we do not want to do that by default. OTOH
> providing an alternative libc is something tricky if we do not want it
> to do it without breaking systems. Someone has to come with a patch that
> is well tested.

Most unwinders should be able to use asynchronous unwind tables, which
only impact disk size (and the size of VM mappings).



Bug#951191: Backport /proc-based lchmod/fchmodat emulation

2020-02-12 Thread Florian Weimer
Unfortunately, this change tickles an XFS bug:

  



Bug#951191: Backport /proc-based lchmod/fchmodat emulation

2020-02-12 Thread Florian Weimer
Package: src:glibc
Version: 2.28-10

gnulib has added emilation for lchmod/fchmodat.  Since this is a
run-time test, binaries built against glibc with these patches will
not work correctly on older glibc version.  (glibc upstream did not
want symbol version markup for this change.)

The backport consists of these patches:

commit 173ec37bb2af6e30892a141d74d42db5957ddd36
Author: Florian Weimer 
Date:   Sun Feb 9 11:50:44 2020 +0100

support: Add the xlstat function

commit f6233ab412c3bebebacf65745e775e01506dd58d
Author: Florian Weimer 
Date:   Sun Feb 9 11:51:08 2020 +0100

Linux: Add io/tst-o_path-locks test

The O_PATH-based fchmodat emulation will rely on the fact that closing
an O_PATH descriptor never releases POSIX advisory locks, so this
commit adds a test case for this behavior.

commit 6b89c385d8bd0700b25bac2c2d0bebe68d5cc05d
Author: Florian Weimer 
Date:   Wed Jan 22 18:56:04 2020 +0100

io: Implement lchmod using fchmodat [BZ #14578]

commit 752dd17443e55a4535cb9e6baa4e550ede383540
Author: Florian Weimer 
Date:   Wed Jan 22 19:01:20 2020 +0100

Linux: Emulate fchmodat with AT_SYMLINK_NOFOLLOW using O_PATH [BZ #14578]

/proc/self/fd files are special and chmod on O_PATH descriptors
in that directory operates on the symbolic link itself (like lchmod).

commit 47136d6cc38c425b150dda83989303ac55f6443c
Author: Florian Weimer 
Date:   Tue Feb 11 16:22:19 2020 +0100

io: Add io/tst-lchmod covering lchmod and fchmodat



Bug#948396: New glibc broke existing app due to historic stack alignment

2020-01-14 Thread Florian Weimer
* Petr Vandrovec:

> Florian Weimer wrote on 1/7/2020 9:31 PM:
>> * Petr Vandrovec:
>> 
>>> As far as I can tell, while x86-64 ABI requires stack to be aligned
>>> on entry to the functions, x86 ABI does not have any such
>>> requirement, and so glibc should align stack itself if it wants to
>>> use XMM instructions that require aligned values.
>> 
>> The i386 ABI was changed after its initial release to require
>> additional stack alignment.
>
> That's a problem.
>
>> If you want to build glibc for i386 with SSE2 enabled (for example,
>> with -march=x86-64), you need to build it with -mrealignstack as well.
>> I'm not aware of any remaining issues with this combination.
>
> I do not want to rebuild anything, I just want things to work :-( 

This comment was directed at the glibc maintainers, sorry.  (The
option is actually called -mstackrealign.)

> libc6:i386 is built without SSE2 support, and takes precedence over 
> libc6-i386, so that is how I've "solved" problem.
>
> Should be libc6-i386 named (after obsolete/virtual) libc6-i686 if it 
> requires SSE2 and new stack alignment?

I think the proper fix would be to build glibc with -mstackrealign.



Bug#948396: New glibc broke existing app due to historic stack alignment

2020-01-07 Thread Florian Weimer
* Petr Vandrovec:

> As far as I can tell, while x86-64 ABI requires stack to be aligned
> on entry to the functions, x86 ABI does not have any such
> requirement, and so glibc should align stack itself if it wants to
> use XMM instructions that require aligned values.

The i386 ABI was changed after its initial release to require
additional stack alignment.

If you want to build glibc for i386 with SSE2 enabled (for example,
with -march=x86-64), you need to build it with -mrealignstack as well.
I'm not aware of any remaining issues with this combination.



Bug#941277: dispatch function missing in header file generated for RPC service

2019-09-27 Thread Florian Weimer
* Simon Richter:

> while implementing an RPC service (in 2019, no less!) I found out that the
> dispatch function generated by rpcgen is not listed in the generated header
> file, so if the service is generated without a main function or inetd
> interface, the code using it needs to create its own declaration.
>
> The signature is easy to guess, but nonetheless I think it should be
> provided by the header.

Ugh, can you describe exactly what is missing?  Then I can file it
here (or just submit a patch):

  

Thanks.

(I'm not sure if we are going to patch glibc's rpcgen for this; nobody
is supposed to use it these days.)



Bug#874160: Fedora has C.UTF-8

2019-09-27 Thread Florian Weimer
* Adam Borowski:

> Looks like Fedora has C.UTF-8 now, and even backported this change to their
> stable releases:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=902094
>
> They're not upstream, but a good part of distros that are not downstream
> from Debian are downstream from Fedora.  This availability makes defaulting
> to C.UTF-8 that more viable.

Please note that Fedora's C.UTF-8 is distinct from Debian's,
unfortunately.  We really need to get this upstream for consolidation.



Bug#934752: libc6: SEGFAULTs caused by tcache after upgrade to Buster

2019-08-27 Thread Florian Weimer
* Pavel Matěja:

> Sorry for late answer.
>
> On 17. 08. 19 22:18, Florian Weimer wrote:
>> * Pavel Matěja:
>>
>>> The strange means they appear only on 2 servers out of 6.
>>> Servers with Xeon E5606 and Pentium G6950 were running fine while Xeon
>>> E3-1220 v6 produced crashes.
>>> It did not matter if the host Debian was Stretch or Buster.
>> Do you see crashes on stretch as well?  What does the backtrace look
>> like there?

> I newer saw the SEGFAULT when we had Stretch based chroot.
>
> I had just one SEGFAULT on Stretch host but I didn't collect coredumps
> back then.
> Unfortunately the server is already running Buster.
> Since the bug is caused by new libc in chroot I should be able to
> install just kernel from Stretch and wait for the SEGFAULT, right?
> I think the backtrace will be the same anyway.

If I recall correctly, stretch doesn't have the tcache code.  If the
crash happened there as well, it's something else.

>>> SSLv3 and TLS code path looked quite distinct to cause the same problem.
>>> Based on info that SEGFAULTs are related to memory allocation in new
>>> libc and CPU performance I found
>>> http://51.15.138.76/patch/17499/
>>> where Wilco Dijkstra discuss some problems with tcache which "leads to
>>> various crashes in benchtests"
>> I was under the impression that this problem only occurs if one of the
>> tunables has an out-of-bounds value.  Do you set any tunables?

> No, I didn't even know they existed.
> I did not read the libc sources yet so I don't know what does the
> patch actually fixes neither if it helps with my problem.

Then the patch will not help to fix the crash.

(By the way, even if the crash goes away if you use a tunable to disable
the thread cache, it could still be timing-related.  It's definitely
possible that the faster malloc/free implementation exposes pre-existing
data races.)

Thanks,
Florian



Bug#924712: crypt() not available _XOPEN_SOURCE is defined

2019-08-25 Thread Florian Weimer
* Francesco Poli:

> Hello everyone,
> I am sorry to ask, but... I cannot understand what's the status of
> [this bug report].
>
> [this bug report]: 
>
> A serious bug for libc6-dev without any apparent activity since last
> March?  Sure there must have been some hidden progress that I cannot
> see.

We provided a solution acceptable to the reporter.  I do not think
further action is needed on the glibc side.  The manual page needs to
be updated to reflect the change, but that's not part of glibc.



Bug#934752: libc6: SEGFAULTs caused by tcache after upgrade to Buster

2019-08-17 Thread Florian Weimer
* Pavel Matěja:

> The strange means they appear only on 2 servers out of 6.
> Servers with Xeon E5606 and Pentium G6950 were running fine while Xeon 
> E3-1220 v6 produced crashes.
> It did not matter if the host Debian was Stretch or Buster.

Do you see crashes on stretch as well?  What does the backtrace look
like there?

> SSLv3 and TLS code path looked quite distinct to cause the same problem.
> Based on info that SEGFAULTs are related to memory allocation in new 
> libc and CPU performance I found
> http://51.15.138.76/patch/17499/
> where Wilco Dijkstra discuss some problems with tcache which "leads to 
> various crashes in benchtests"

I was under the impression that this problem only occurs if one of the
tunables has an out-of-bounds value.  Do you set any tunables?



Bug#934080: [libc6] Significant degradation in the memory effectivity of the memory allocator

2019-08-14 Thread Florian Weimer
* Roman Savochenko:

>> Is there a way to reproduce your results easily?  Upstream, we're
>> looking for workloads which are difficult to handle for glibc's malloc
>> and its default settings, so that we hopefully can improve things
>> eventually.
>
> This way of the ready builds of the application and LiveDisks is
> simplest one for me, than writing a test application with simulation
> such sort complex load, so you can already install the application,
> start and observer.

I meant: Is there a reproduction recipe someone could use, without being
familiar with the application?

Thanks,
Florian



Bug#934080: [libc6] Significant degradation in the memory effectivity of the memory allocator

2019-08-09 Thread Florian Weimer
* Roman Savochenko:

> Thanks you Florian, setting the environment MALLOC_ARENA_MAX=1 I have
> got the memory effectivity some better even than in Debian 7!

Is there a way to reproduce your results easily?  Upstream, we're
looking for workloads which are difficult to handle for glibc's malloc
and its default settings, so that we hopefully can improve things
eventually.

Thanks,
Florian



Bug#934080: [libc6] Significant degradation in the memory effectivity of the memory allocator

2019-08-07 Thread Florian Weimer
* Roman Savochenko:

> Initial condition of the problem representing is a program in the
> single source code, built on-and for Debian 7, 8, 9, 10 with a result
> in the Live disks.

I think glibc 2.13 as shipped by Debian was not built with
--enable-experimental-malloc, so it doesn't use arenas.  This can
substantially decrease RSS usage compared to later versions.  You can
get similar behavior by setting the MALLOC_ARENA_MAX environment
variable to 1 or 2.

Debian 10 also adds a thread cache, which further increases RSS size.
See the manual

  


for details how to change thread cache behavior.

Thanks,
Florian



Re: Options for 64-bit time_t support on 32-bit architectures

2019-07-21 Thread Florian Weimer
* Simon McVittie:

> On Fri, 19 Jul 2019 at 15:13:00 +0300, Adrian Bunk wrote:
>> Remaining usecases of i386 will be old binaries, some old Linux binaries 
>> but especially old software (including many games) running in Wine.
>> Old Linux binaries will still need the old 32bit time_t.
>
> Based on background from my contributions to the Steam Runtime:
>
> I don't have numbers, but you might be surprised how many Linux-supporting
> games are 32-bit. The Steam client itself is currently also 32-bit
> (with some 64-bit subprocesses); this is somewhat deliberate, to act as
> a canary for whether 32-bit code works at all, particularly when combined
> with graphics.
>
> The Steam Runtime (a LD_LIBRARY_PATH library bundle used to run Steam and
> Steam games) is built on an increasingly ancient version of Ubuntu, but
> it tries to use newer libraries of the same SONAME from the host system
> where available, which they often will be, because people who install
> Steam probably also install Wine, which has 32-bit dependencies. If those
> libraries have an incompatible ABI involving 64-bit time_t, and it is used
> at the ABI "surface" between a host-system library and a Steam Runtime
> library or the game, then 32-bit games, and the Steam client itself,
> will crash.

We could in theory bump soname for these libraries, but that has the
unfortunate side effect that it will likely leak to 64-bit
architectures, creating more work for everyone.

I don't see a good way to maintain those libraries with a single-ABI
approach.  So if that's an important use case, it would be a fairly
strong case against it, I think.



Re: Options for 64-bit time_t support on 32-bit architectures

2019-07-19 Thread Florian Weimer
* Adrian Bunk:

> On Fri, Jul 19, 2019 at 07:13:28PM +0200, Florian Weimer wrote:
>> * Adrian Bunk:
>>...
>> For comparison, the original plan was to provide a macro, perhaps
>> -D_TIME_BITS=32 and -D_TIME_BITS=64, to select at build time which ABI
>> set is used (“dual ABI”).
>
> To me this would sound like more trouble than a clear break,
> similar to the mostly working dual OpenSSL 1.0 and 1.1 support
> in stretch.

Could be.  But it would enable keeping i386 at the old ABI while still
building the distribution with newer glibc versions with current
kernel headers (the libc-alpha discussion is evolving regarding the
precise nature of the enablement approach).

Other 32-bit architectures could opt to do the transition now.

>> Similar to the LFS support, with the
>> additional property that binaries built in either mode should continue
>> to work on kernels which predate support for the *_time64 system
>> calls.
>
> Debian does not support running on kernels older than the one in the
> previous stable release.
>
> E.g. Qt in Debian 9 unconditionally uses the getrandom syscall that is 
> not in kernel 3.16 in Debian 7.

The 64-bit system calls arrived in Linux 5.1, so I think the fallback
will be needed for quite some time.



Re: Options for 64-bit time_t support on 32-bit architectures

2019-07-19 Thread Florian Weimer
* Adrian Bunk:

> [ only speaking for myself ]
>
> On Thu, Jul 18, 2019 at 11:05:53PM +0200, Florian Weimer wrote:
>>...
>> The consequence is that in order to build 32-bit-time_t libraries
>> (Gtk, for example), an old glibc needs to be kept around.  In
>> practice, it would probably mean that it is impossible to maintain a
>> set of 32-bit-time_t libraries in a classic distribution build
>> environment (with a unified buildroot and native builds).
>>...
>> Do you want to build 32-bit libraries (besides glibc) which are
>> compatible with legacy applications, with a 32-bit time_t, in the
>> future?  Or is a world where time_t is pretty much always 64 bit
>> something that would be acceptable?
>
> So this is an ABI-incompatible change that would result in new Debian 
> architectures, similar to arm (OABI), armel (EABI softfp) and armhf 
> (EABI hardfp) being different Debian architectures for 32bit little 
> endian ARM?

Not quite.  glibc would still be able to run binaries from the old ABI
and the new ABI.  But under the proposal, you would have to use an old
glibc (missing new system call wrappers etc.) if you want to build
libraries that provide interfaces involving 32-bit time_t.

So in practice, it would likely mean a new Debian architecture, or a
de-facto ABI bump for i386 and armhfp.

For comparison, the original plan was to provide a macro, perhaps
-D_TIME_BITS=32 and -D_TIME_BITS=64, to select at build time which ABI
set is used (“dual ABI”).  Similar to the LFS support, with the
additional property that binaries built in either mode should continue
to work on kernels which predate support for the *_time64 system
calls.  The should also use the vDSO as before.  All these
requirements make an implementation quite hairy, hence the desire for
simplification.

> There are two current release architectures where it is at least 
> imaginable that they will still be around closer to the year 2038:
> i386 and armhf

Right.

> For i386 the last newly released 32bit-only hardware were some early
> Intel Atoms 10 years ago, and when the AMD Geode goes out of production
> soon there might be no hardware in production left.
> There are still surprisingly many people using Debian on 32bit-only
> hardware, but in 20 years this will have changed.

You have thankfully edited out the Intel Quark. 8-)

> Remaining usecases of i386 will be old binaries, some old Linux binaries 
> but especially old software (including many games) running in Wine.
> Old Linux binaries will still need the old 32bit time_t.
> Which options are viable from a Wine point of view?

I talked to a Wine developer in the office, and Wine doesn't directly
expose the time_t ABI to Windows binaries (which isn't suprising).
It's also already been ported to 32-bit systems with a 64-bit time_t.
I expect that this is not a determining factor.

> For armhf new hardware might be available long enough to come close
> to the year 2038, this might require a new architecture at some point.

The push for a 64-bit time_t definitely comes from the embedded 32-bit
processor direction.

For glibc, providing a dual ABI configurable at build time one or all
32-bit architectures probably does not make much of a different in
terms of overall effort.  This means that if we need to produce the
dual ABI for i386, armhfp will likely get it as well.



Options for 64-bit time_t support on 32-bit architectures

2019-07-18 Thread Florian Weimer
There is an effort under way to enhance glibc so that it can use the
Y2038 support in the kernel.  The result will be that more 32-bit
architectures can use a 64-bit time_t.  (Currently, it's x86-64 x32
only.)

Originally, the plan was to support both ABIs in glibc for building
new applications, similar to what is currently possible with
-D_FILE_OFFSET_BITS=64 for changing the size of off_t.  However, this
turned out to be difficult to implement, and so far, no one has posted
patches which appear to be reasonably correct and complete.

The latest proposal is a single-ABI mode for development:

  

Old binaries with a 32-bit time_t will continue to run, but new
binaries built against a current glibc will always use a 64-bit time_t
under this approach.

The consequence is that in order to build 32-bit-time_t libraries
(Gtk, for example), an old glibc needs to be kept around.  In
practice, it would probably mean that it is impossible to maintain a
set of 32-bit-time_t libraries in a classic distribution build
environment (with a unified buildroot and native builds).

I do not have a strong opinion about this because I personally do not
care about 32-bit architectures at all (sorry).  I would like to
solicit Debian's feedback on this matter.

Do you want to build 32-bit libraries (besides glibc) which are
compatible with legacy applications, with a 32-bit time_t, in the
future?  Or is a world where time_t is pretty much always 64 bit
something that would be acceptable?



Bug#924891: glibc: FTBFS: /<>/build-tree/amd64-libc/conform/UNIX98/ndbm.h/scratch/ndbm.h-test.c:1:10: fatal error: ndbm.h: No such file or directory

2019-03-27 Thread Florian Weimer
retitle 924891 glibc: misc/tst-pkey fails due to cleared PKRU register after 
signal in amd64 32-bit compat mode 
thanks

* Lucas Nussbaum:

> On 27/03/19 at 08:48 +0100, Florian Weimer wrote:
>> > If that's useful, I can easily provide access to an AWS VM to debug this
>> > issue.
>> 
>> Oh, that would be quite helpful indeed.
>
> Can you send your SSH key? (I thought there was a way to get the SSH key
> for a DD, but I cannot find it anymore)
>
> Then you will be able to ssh to root@18.184.55.40.
> There's sbuild and schroot setup on the VM.
>
> When you are done, please 'poweroff' the machine, which will terminate
> it.

The issue reproduces outside the chroot, with the stretch userland.

What happens is that once we get out of the SIGUSR1 signal handler,
the PKRU register has value zero.  This happens around this code in
the test:

  /* Check that in a signal handler, there is no access.  */
  xsignal (SIGUSR1, _handler);
  xraise (SIGUSR1);
  xsignal (SIGUSR1, SIG_DFL);
  TEST_COMPARE (sigusr1_handler_ran, 1);

I checked the following (via a breakpoint in pkey_get; I don't think
GDB can read the PKRU register directly): Inside the SIGUSR1 signal
handler, PKRU has value 0x5554, as expected for this kernel, but
after the return, we get zero.  This is the first time a signal is
delivered on the main thread, so it's consistent with fairly broken
signal handling as far as the PKRU register is concerned.  I guess
clearing PKRU in this way might even constitute a minor security bug
(because the zero value means no restrictions).

This commit looks highly relevant:

commit a4455082dc6f0b5d51a23523f77600e8ede47c79
Author: Dave Hansen 
Date:   Wed Jun 8 10:25:33 2016 -0700

x86/signals: Add missing signal_compat code for x86 features

The 32-bit siginfo is a different binary format than the 64-bit
one.  So, when running 32-bit binaries on 64-bit kernels, we have
to convert the kernel's 64-bit version to a 32-bit version that
userspace can grok.

If the siginfo_t layout is incorrect (with regards to what the
hardware writes), I expect that we might end up copying back the wrong
PKRU value.

I'm not sure what to do here.  This really looks like a kernel bug.
Maybe we should just verify that this is fixed in the buster kernel
and move on?

Lucas, can you run your rebuild tests on newer kernels?



Bug#924891: glibc: FTBFS: /<>/build-tree/amd64-libc/conform/UNIX98/ndbm.h/scratch/ndbm.h-test.c:1:10: fatal error: ndbm.h: No such file or directory

2019-03-27 Thread Florian Weimer
* Lucas Nussbaum:

> On 26/03/19 at 23:10 +0100, Aurelien Jarno wrote:
>> On 2019-03-22 17:30, Florian Weimer wrote:
>> > > About the archive rebuild: The rebuild was done on EC2 VM instances from
>> > > Amazon Web Services, using a clean, minimal and up-to-date chroot. Every
>> > > failed build was retried once to eliminate random failures.
>> > 
>> > I believe the actual test failure is tst-pkey.
>> > 
>> > Presumably, this rebuild was performed on some Xeon SP CPU.  Do you
>> > know which model?  Do you have any information about the kernel and
>> > hypervisor used?
>> > 
>> > 32-bit protection key support has had issues from time to time.
>> 
>> Do you have some more details about the issue? Is it a glibc or a kernel
>> problem?
>> 
>> If we can't fix the issue easily on the libc side, I guess the way to
>> fix that is to XFAIL that test on 32-bit x86. 
>
> If that's useful, I can easily provide access to an AWS VM to debug this
> issue.

Oh, that would be quite helpful indeed.



Re: Glibc 2.28 breaks collation for PostgreSQL (and others?)

2019-03-25 Thread Florian Weimer
* Christoph Berg:

> with the update to glibc 2.28, collation aka sort ordering is
> changing:
>
> $ echo $LANG
> de_DE.utf8
> $ (echo 'a-a'; echo 'a a'; echo 'a+a'; echo 'aa') | sort
>
> stretch:
>   aa
>   a a
>   a-a
>   a+a
>
> buster:
>   a a
>   a+a
>   a-a
>   aa
>
> A vast number of locales is affected, including en_US, possibly all of
> them.
>
> For PostgreSQL, this means that the ordering of indexes on disk is
> becoming corrupt, and all "text" (varchar, char, ...) indexes need to
> be rebuilt. (And worse, if that is not done immediately, the tables
> might become corrupt because some tuples aren't index-visible anymore
> due to the incorrect btree ordering.)

That's fairly normal in a glibc update.  glibc upstream prefers it
this way.  I've discussed it several times with other glibc
maintainers.

My understanding is that ICU provides versioned collation tables,
which would allow you to avoid this issue.

  

> I've been thinking about this for some time, and the best I could come
> up so far is "raise a debconf note that people need to invoke REINDEX
> DATABASE". The open question about this plan is, how should this note
> be triggered.

That might not work for unique indices because locale data changes
could cause strings to sort the same that were distinct before the
update.



Bug#924891: glibc: FTBFS: /<>/build-tree/amd64-libc/conform/UNIX98/ndbm.h/scratch/ndbm.h-test.c:1:10: fatal error: ndbm.h: No such file or directory

2019-03-22 Thread Florian Weimer
> About the archive rebuild: The rebuild was done on EC2 VM instances from
> Amazon Web Services, using a clean, minimal and up-to-date chroot. Every
> failed build was retried once to eliminate random failures.

I believe the actual test failure is tst-pkey.

Presumably, this rebuild was performed on some Xeon SP CPU.  Do you
know which model?  Do you have any information about the kernel and
hypervisor used?

32-bit protection key support has had issues from time to time.

Thanks.



Bug#924712: crypt() not available _XOPEN_SOURCE is defined

2019-03-21 Thread Florian Weimer
* Laurent Bigonville:

> Le 19/03/19 à 19:43, Florian Weimer a écrit :
>> * Laurent Bigonville:
>>
>>> Package: libc6-dev
>>> Version: 2.28-8
>>> Severity: serious
>>>
>>> Hi,
>>>
>>> The crypt.3 manpage, state that _XOPEN_SOURCE should be define for
>>> crypt() to be available.
>>>
>>> But it looks that it's currently the opposite, if _XOPEN_SOURCE is
>>> defined, the function cannot be found.

>> Can you compile the software using _DEFAULT_SOURCE (well, the default)
>> or _GNU_SOURCE instead?
>
> Yes, the software can be compile when _XOPEN_SOURCE is not defined or 
> when _GNU_SOURCE is defined instead

Sorry, what I was trying to ask is whether this would be an acceptable
change for you.



Bug#924712: crypt() not available _XOPEN_SOURCE is defined

2019-03-19 Thread Florian Weimer
* Laurent Bigonville:

> Package: libc6-dev
> Version: 2.28-8
> Severity: serious
>
> Hi,
>
> The crypt.3 manpage, state that _XOPEN_SOURCE should be define for
> crypt() to be available.
>
> But it looks that it's currently the opposite, if _XOPEN_SOURCE is
> defined, the function cannot be found.

Can you compile the software using _DEFAULT_SOURCE (well, the default)
or _GNU_SOURCE instead?

We do not want to provide the CRYPT extension anymore because it
implies not just support for the crypt function, but also for the DES
encryption functions, which definitely do not want.  In _XOPEN_SOURCE
mode, it's either all of these functions or none of them (and we chose
the latter because of DES), otherwise glibc wouldn't conform to the
interface specification.

We definitely should update the manual page, though.



Bug#923802: Acknowledgement (pthread: dead-lock while pthread_cond_destroy())

2019-03-06 Thread Florian Weimer
* Joël Krähemann:

> This happens as you call pthread_cond_destroy() twice on the very same
> cond variable.

Surely that's an application bug.  Why do you think this is a glibc
issue?

Thanks,
Florian



Bug#920047: glibc: CVE-2016-10739: getaddrinfo should reject IP addresses with trailing characters

2019-01-21 Thread Florian Weimer
* Salvatore Bonaccorso:

> CVE-2016-10739[0]:
> | In the GNU C Library (aka glibc or libc6) through 2.28, the getaddrinfo
> | function would successfully parse a string that contained an IPv4
> | address followed by whitespace and arbitrary characters, which could
> | lead applications to incorrectly assume that it had parsed a valid
> | string, without the possibility of embedded HTTP headers or other
> | potentially dangerous substrings.
>
> If you fix the vulnerability please also make sure to include the
> CVE (Common Vulnerabilities & Exposures) id in your changelog entry.
>
> For further information see:
>
> [0] https://security-tracker.debian.org/tracker/CVE-2016-10739
> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-10739
> [1] https://sourceware.org/bugzilla/show_bug.cgi?id=20018
>
> Please adjust the affected versions in the BTS as needed.

Would it help if I put a backport on the 2.24 upstream branch?



Bug#906917: sem_timedwait could always block and returns ETIMEOUT but decrements the value on i686 architecture

2019-01-16 Thread Florian Weimer
* Андрей Доценко:

> The problem occurs only when using semaphores in a library that is not
> linked against pthread.

Yes, that's expected.  Sorry I didn't see this earlier—we have an
upstream bug about this:

  

In general, underlinking produces broken binaries.

Thanks,
Florian



Bug#761300: libc6: putchar does not follow stdio

2018-12-28 Thread Florian Weimer
* Sven Joachim:

> Am 14.10.2018 um 13:38 schrieb Florian Weimer:
>
>> * Sven Joachim:
>>
>>> This result is rather surprising.  After all, "putchar('x')" is supposed
>>> to do the same as "putc('x', stdout)", but here it does not.
>>
>> Can you reproduce this with something newer than 2.13-38+rpi2+deb7u3?
>> Or on something else besides armhf?
>
> Surely, I tested 2.27-6 on amd64.

Eh, right.  We have this in glibc:

int
putchar (int c)
{
  int result;
  _IO_acquire_lock (_IO_stdout);
  result = _IO_putc_unlocked (c, _IO_stdout);
  _IO_release_lock (_IO_stdout);
  return result;
}

_IO_stdout is the variable to which stdout points to default, so this
code was simply not adjusted when the assignment-to-stdout extension
was implemented.  This should use stdout instead.  The puts function
has the same problem.

It looks to me we can get away with fixing this bug.



Bug#912665: (geen onderwerp)

2018-11-02 Thread Florian Weimer
* Frederik Himpe:

> FYI, this is where it crashes:
>
> #0  0x7fc0172239c6 in _IO_fgets (buf=0x7ffc9b2b1640 "
> /dev/aivmhost3-vg/ceph-node1-storage:ceph-ff35163d-b03f-4dbf-a6ce-155730069dc0:4194304:-1:8:8:-1:4096:511:0:511:ZNexTV-ylVb-ltMP-T8Zu-ZklU-cN1I-dETf5o\n",
> n=1024, fp=0x1a90030)
> at iofgets.c:47

This is the first dereference of the file stream pointer in fgets, so
this suggests a use-after-free application bug (or use-after-fclose in
this case).  It should be visible in valgrind as well.

Thanks,
Florian



Bug#761300: libc6: Printf("%c",'x') does not follow stdio

2018-10-14 Thread Florian Weimer
* Sven Joachim:

> This result is rather surprising.  After all, "putchar('x')" is supposed
> to do the same as "putc('x', stdout)", but here it does not.

Can you reproduce this with something newer than 2.13-38+rpi2+deb7u3?
Or on something else besides armhf?



Bug#785651: glibc: test run times out on ci.debian.net; maybe don't force a build every time

2018-07-30 Thread Florian Weimer
* Paul Gevers:

> Hi Florian,
>
> On 29-07-18 13:26, Florian Weimer wrote:
>> I'm not sure why it is necessary to build glibc three times (unless
>> it's impossible to get multi-arch packages into the buildroot).
>
> I am not sure if I understand what you mean, but currently having
> multiple arches available in the autopkgtest testbed isn't supported. I
> have seen packages try (gnupg2), but this goes easily wrong considering
> the unstable-to-testing migration setup. If there is a real need for
> this, it should come from autopkgtest.

Sorry, I never worked on the Debian toolchain, so my phrasing was
poor.

In concrete terms, what I meant was: Why build libc6-i386 on amd64
when there is a libc6:i386 package as well?

In Fedora, there's a restriction that buildds cannot install foreign
architecture packages.  Some packages need a 32-bit glibc on a 64-bit
builder, too.  (Typical gcc flags, for example, or fake amd64 packages
such as amd64).  That made me wonder if Debian has a similar
restriction for its buildds.



Bug#785651: glibc: test run times out on ci.debian.net; maybe don't force a build every time

2018-07-29 Thread Florian Weimer
* Paul Gevers:

> On Sun, 01 Apr 2018 21:56:33 +0200 Florian Weimer  wrote:
>> > I have no idea. On a fast 4-cores amd64 machine and for the 3 flavours
>> > built on amd64, the glibc takes around 20 minutes to build and the
>> > testsuite around 2h to run.
>> 
>> This is still rather slow.  I see native builds on relatively current
>> hardware taking 2 minutes, plus 12 to 15 minutes to build and run the
>> test suite (all with parallel make, although parallel make for tests
>> is disabled automatically for some subdirectories).  200 minutes on
>> current (amd64) hardware sounds quite excessive.
>
> I just did a retry on our infrastructure and it ran in 57 minutes. But
> it ran on one of the two big workers (8 cores and 30 GB memory). We want
> to make all workers equal and we are going down to 2 cores and 7.2 GB.
>
> Could it be that the memory is the actual problem and/or also an issue?

I looked at the build process, and the amd64 package actually builds
glibc three times (for amd64, i386 and x32).  So 57 minutes is
actually very close to the numbers I gave.

I'm not sure why it is necessary to build glibc three times (unless
it's impossible to get multi-arch packages into the buildroot).  If
you disable kernel support for the i386 and x32 subarchitectures, at
those test suites will not run, which will speed up the build
somewhat.



Bug#902851: libc-bin: ldd stopped working with 32-bit binaries on amd64 machine

2018-07-07 Thread Florian Weimer
* Alexandra N. Kossovsky:

> Please close this bug.  I definitely saw the issue yesterday, but it has 
> somehow gone today.  I'll return to you if I see it again and understand 
> what triggers it.

The related Fedora bug

  https://bugzilla.redhat.com/show_bug.cgi?id=1596312

appears to have been a kernel regression (unconditional exit status
zero from 32-bit processes, or something like that).



Bug#861116: Fixed in glibc 2.28

2018-07-01 Thread Florian Weimer
The issue should be fixed with this upstream commit:

commit c402355dfa7807b8e0adb27c009135a7e2b9f1b0
Author: Florian Weimer 
Date:   Tue Jun 26 10:24:52 2018 +0200

libio: Disable vtable validation in case of interposition [BZ #23313]

<https://sourceware.org/git/gitweb.cgi?p=glibc.git;a=commitdiff;h=c402355dfa7807b8e0adb27c009135a7e2b9f1b0>



Re: Arm ports build machines (was Re: Arch qualification for buster: call for DSA, Security, toolchain concerns)

2018-06-29 Thread Florian Weimer
* Luke Kenneth Casson Leighton:

>  that is not a surprise to hear: the massive thrashing caused by the
> linker phase not being possible to be RAM-resident will be absolutely
> hammering the drives beyond reasonable wear-and-tear limits.  which is
> why i'm recommending people try "-Wl,--no-keep-memory".

Note that ld will sometimes stuff everything into a single RWX segment
as a result, which is not desirable.

Unfortunately, without significant investment into historic linker
technologies (with external sorting and that kind of stuff), I don't
think it is viable to build 32-bit software natively in the near
future.  Maybe next year only a few packages will need exceptions, but
the number will grow with each month.  Building on 64-bit kernels will
delay the inevitable because more address space is available to user
space, but that's probably 12 to 18 month extended life-time for
native building.



Re: Arch qualification for buster: call for DSA, Security, toolchain concerns

2018-06-28 Thread Florian Weimer
* Niels Thykier:

> armel/armhf:
> 
>
>  * Undesirable to keep the hardware running beyond 2020.  armhf VM
>support uncertain. (DSA)
>- Source: [DSA Sprint report]

Fedora is facing an issue running armhf under virtualization on arm64:

  
  

Unless the discussion has moved somewhere where I can't follow it, no
one seems to have solid idea what is going on.  It's also not clear
that this configuration has substantial vendor or community support.
This makes me concerned that virtualization is a viable path forward
here.

(The discussion on the GCC list started off with a misdirection, sorry
about that.  The brief assumption that this was a hardware quirk is
likely quite wrong.)

>  * Concern for mips, mips64el, mipsel and ppc64el: no upstream support
>in GCC
>(Raised by the GCC maintainer; carried over from stretch)

I'm surprised to read this.  ppc64el features prominently in the
toolchain work I do (though I personally do not work on the GCC side).
>From my point of view, it's absolutely not in the same category as the
MIPS-based architectures.



Bug#880846: libc-bin: libnss_compat is deprecated and nsswitch should stop using it on new installation

2018-06-20 Thread Florian Weimer
* Laurent Bigonville:

> According to the release note of 2.26, the nss_compat module is
> deprecated[0].

> [0]https://sourceware.org/ml/libc-announce/2017/msg1.html

I think we made changes so that it is no longer deprecated, by
removing the hard NIS dependency.  It shouldn't be used by default
nevertheless.



Bug#900025: /usr/lib/x86_64-linux-gnu/libm.so: invalid ELF header

2018-05-25 Thread Florian Weimer
* Aurelien Jarno:

> Now I don't find this common/utils.c file in the simple-scan sources.

This looks like a known hplip bug:

https://bugzilla.redhat.com/show_bug.cgi?id=1347231

More recent sources try to load libm.so.6 as well.  Note that shared
objects which use libm (or any libc) functions and are not themselves
linked against the relevant shared objects have no ABI guarantees
whatsoever and can break with a glibc update.  (Exceptions are objects
which were linked against glibc 2.0, before symbol versioning was
introduced.)



Bug#620887: Please add a shm_mkstemp() function

2018-05-18 Thread Florian Weimer

On 05/16/2018 10:25 PM, Jakub Wilk wrote:

* Goswin von Brederlow , 2011-04-04, 23:33:

int shm_mkstemp(char *template);


FWIW, this function is available on OpenBSD:
https://man.openbsd.org/shm_mkstemp.3


We have memfd_create nowadays.  It's not exactly identical because it 
creates an unnamed file, but perhaps it is close enough?  If not, we'd 
need actual use cases to justify to add it to glibc.


Thanks,
Florian



Bug#897373: libc6: feof(file) always false when forking after read

2018-05-10 Thread Florian Weimer
* David Beniamine:

> On Thu, May 10, 2018 at 07:06:03PM +0200, Florian Weimer wrote:
>> * David Beniamine:
>> 
>> > int do_fork() {
>> > pid_t pid;
>> >
>> > switch (pid = fork()) {
>> > case -1:
>> > fprintf(stderr, "Fork failed\n");
>> > return -1;
>> > case 0:
>> > exit(-1);
>> 
>> Does the issue go away when you call _exit instead of exit?
>> 
> It goes away with _exit, indeed.

According to POSIX, exit is required to flush all streams, and fflush
is required to reset the position of the underlying file descriptor
(more precisely, the open file description) to the current read
position.  That affects the descriptor in the parent, too.  I'm not
sure if this is actually a glibc bug.



Bug#897373: libc6: feof(file) always false when forking after read

2018-05-10 Thread Florian Weimer
* David Beniamine:

> int do_fork() {
> pid_t pid;
>
> switch (pid = fork()) {
> case -1:
> fprintf(stderr, "Fork failed\n");
> return -1;
> case 0:
> exit(-1);

Does the issue go away when you call _exit instead of exit?



Bug#895981: please cleanup /var/cache/nscd on restart

2018-04-30 Thread Florian Weimer
* Carlos O'Donell:

> Then each registered file, like /etc/resolv.conf, is watched via
> inotify for any changes, and if a change is detected and
> finfo->call_res_init was true (and it's true only for resolv.conf)
> then we call res_init().

But res_init does not flush the nscd cache, doesn't it?



Bug#895981: please cleanup /var/cache/nscd on restart

2018-04-29 Thread Florian Weimer
* Harald Dunkel:

> I am using both systemd and sysvinit-core, but I am not sure which one
> was active when I ran into this problem.
>
> Consider a split DNS setup for a remote network. I had started an IPsec
> connection to the remote side. /etc/resolv.conf was changed to include
> the new internal DNServer on the remote side, but a host lookup gave me
> still the old external address. Stopping nscd did not help, AFAIR.

That's arguably a bug in nscd.  It should flush the cache each time it
detects a change in /etc/resolv.conf (or /etc/gai.conf, for that
matter).



Bug#785651: glibc: test run times out on ci.debian.net; maybe don't force a build every time

2018-04-02 Thread Florian Weimer
* Aurelien Jarno:

> I have no idea. On a fast 4-cores amd64 machine and for the 3 flavours
> built on amd64, the glibc takes around 20 minutes to build and the
> testsuite around 2h to run.

This is still rather slow.  I see native builds on relatively current
hardware taking 2 minutes, plus 12 to 15 minutes to build and run the
test suite (all with parallel make, although parallel make for tests
is disabled automatically for some subdirectories).  200 minutes on
current (amd64) hardware sounds quite excessive.



Bug#887169: libc6: recent upgrade to 2.26-3 broke Steam games (Civ5)

2018-01-15 Thread Florian Weimer

On 01/15/2018 12:22 AM, Aurelien Jarno wrote:

I don't think it is actually the consensus, only Arch Linux has chosen
this solution, and building the whole glibc with this option will have
an impact of the performances for all binaries, not only the broken
Steam ones. I therefore don't think it's the right way to fix the bug.


For Fedora, I disabled multiarch support for the i386 builds because 
it's not entirely unlikely that there will be similar issues.


If we could assume SSE2 support and built the distribution with 
-march=x86-64, we would likely have to go the -mstackrealign route.  But 
this is just an educated guess.


Thanks,
Florian



Bug#879093: Segfault in libc6 while using xrdp-sesman on Stretch

2017-10-24 Thread Florian Weimer
* Gilles MOREL:

> I repported this bug for the package libc6 because the kernel line let
> me think the problem comes from libc6.

It's much more likely that xrdp-sesman calls a glibc function on an
invalid pointer.

> If you want me to provide more log or debugging, please tell me, I
> don't really understand the problem.

You will have to provide a backtrace at least, with debugging symbols
installed.  If you can reproduce the issue on buster, getting
debugging symbols may be easier (I don't know what the current state
of automatic debugging information packaging is on Debian).  Note that
you'll have to install packages with the debugging information for
xrdp-sesman and all its dependencies, not just libc6.



Bug#857909: [libc6-dev] getpid() in child process created using clone(CLONE_VM) returns parent's pid

2017-03-23 Thread Florian Weimer
* John Paul Adrian Glaubitz:

> I would suggest filing a bug report to glibc upstream or posting on
> their mailing list to ask for feedback.

Upstream has since removed the PID cache:

  
  




Bug#858529: libc6: fgets repeats content after fork on stretch only

2017-03-23 Thread Florian Weimer
tags 858529 upstream
forwarded 858529 https://sourceware.org/bugzilla/show_bug.cgi?id=20598
thanks

* Neil Spring:

>   if(fork() == 0) { exit(1); }

exit flushes the stdio buffers in the child.  Upstream concluded that
this leads to undefined behavior:

| Yes, this is about the exit actually.  But reading "2.5.1
| Interaction of File Descriptors and Standard I/O Streams", I think
| this is really undefined, because the required action is not
| performed before the call to fork, and the correct fix is to use
| _exit in the forked child.





Bug#839280: libc6: asprintf(, "%F", 1.0) puts 0.00000 in c on raspberry pi zero v1.3.

2016-10-01 Thread Florian Weimer
* Noah Williams:

>* What led up to the situation? I was building a robot, and needed a 
> raspberry pi zero to send a floating point number formatted as a string to an 
> arduino.
>* What exactly did you do (or not do) that was effective (or
>  ineffective)? I've tried passing bigger numbers than 1.0 (like 100.0) , 
> but it didn't seem to do anything different, "%F %F" does however seem to get 
> the second argument right.
>* What was the outcome of this action? It printed out something like: 
> -0.1 1.0 
>* What outcome did you expect instead? 1.0 0.0

Please post complete, minimal source code, along with a description
how you compiled your program (and for what architecture).  Thanks.



Bug#595790: [Pkg-zfsonlinux-devel] Bug#595790: hostid: useless unless fixed

2016-09-29 Thread Florian Weimer
* Richard Laager:

> Getting back to ZFS and /etc/hostid... I would think that a
> randomly-generated /etc/hostid is probably sufficient. Whether that's
> done in the libc, spl, or zfs package makes no difference to me.

As I tried to explain, the risks of collisions without central
coordination looks rather high.  glibc's current approach, using the
IP address associated with the host name, provides a certain level of
coordination, avoiding duplicates.



Bug#595790: [Pkg-zfsonlinux-devel] Bug#595790: hostid: useless unless fixed

2016-09-28 Thread Florian Weimer
* Michael Stone:

> Other platforms have deprecated gethostid, that's the best way forward
> for linux, IMO.

I agree.  It's the most likely outcome if this issue was reported to
glibc upstream.



Re: segfault in errx

2016-09-28 Thread Florian Weimer
* Florian Weimer:

>> I can reproduce something like this with 2.24-3 on amd64.  valgrind
>> isn't very helpful.
>
> And it needs a UTF-8 locale (C.UTF-8 will do).  Another multi-byte
> locale may work as well.

Bisecting this with the attached script leads to:

commit 18d26750dd8fd328a78cf639fd0ec2494680a2a4
Author: Paul Pluzhnikov <ppluzhni...@google.com>
Date:   Sun Mar 8 09:46:53 2015 -0700

Cleanup: in preparation for fixing BZ #16734, fix memory leaks exposed by
switching fopen()ed streams from mmap to malloc.

This commit has shown up in other context as well:

  <https://sourceware.org/bugzilla/show_bug.cgi?id=20598>

#!/bin/bash

set -x

unset LANG LANGUAGE LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY \
  LC_MESSAGES LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT \
  LC_IDENTIFICATION LC_ALL

fatal () {
exit 255
}

skip () {
exit 255
}

run () {
GCONV_PATH=./iconvdata LOCPATH=. ./elf/ld-linux-x86-64.so.2 --library-path 
.:./math:./elf:./dlfcn:./nss:./nis:./rt:./resolv:./crypt:./mathvec:./nptl "$@"
}

cd ../build || fatal
rm -rf ../build/* || fatal
../git/configure --prefix=/usr --disable-werror || skip
make -j12 || skip
run locale/localedef -f ../git/localedata/charmaps/UTF-8 -i 
../git/localedata/locales/en_US "$PWD/en_US.UTF-8" || skip
LC_ALL=en_US.UTF-8 run /usr/bin/ul /tmp/ul.segf
case $? in
1)
exit 0
;;
139)
exit 1
;;
*)
fatal
;;
esac



Re: segfault in errx

2016-09-28 Thread Florian Weimer
* Florian Weimer:

> * Michael Meskes:
>
>> I recently learned that ul (from bsdmainutils) segfaults when run
>> against the attached file. Some debugging shows that the segfault
>> happens when cleaning up in errx():
>>
>> michael@feivel:~$ ul ul.segf 
>> ul: unknown escape sequence in input: 33, 135
>> Speicherzugriffsfehler
>
> What's the glibc version and architecture?
>
> I can reproduce something like this with 2.24-3 on amd64.  valgrind
> isn't very helpful.

And it needs a UTF-8 locale (C.UTF-8 will do).  Another multi-byte
locale may work as well.

> I'll have to try this on a distribution with better debugging
> information.

Not much luck on Fedora, either.

Based on what ul does, I suspect it's this upstream bug:

  <https://sourceware.org/bugzilla/show_bug.cgi?id=20568>

Or perhaps this one:

  <https://sourceware.org/bugzilla/show_bug.cgi?id=20632>



Re: segfault in errx

2016-09-28 Thread Florian Weimer
* Michael Meskes:

> I recently learned that ul (from bsdmainutils) segfaults when run
> against the attached file. Some debugging shows that the segfault
> happens when cleaning up in errx():
>
> michael@feivel:~$ ul ul.segf 
> ul: unknown escape sequence in input: 33, 135
> Speicherzugriffsfehler

What's the glibc version and architecture?

I can reproduce something like this with 2.24-3 on amd64.  valgrind
isn't very helpful.

ul: unknown escape sequence in input: 33, 135
==16450== Conditional jump or move depends on uninitialised value(s)
==16450==at 0x52A9A63: utf8_internal_loop (loop.c:298)
==16450==by 0x52A9A63: __gconv_transform_utf8_internal (skeleton.c:609)
==16450==by 0x52F26CD: do_length (iofwide.c:463)
==16450== 
==16450== Jump to the invalid address stated on the next line
==16450==at 0x0: ???
==16450==by 0x4224167: ???
==16450==by 0x4024537: ???
==16450==by 0x5833A3F: ???
==16450==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
==16450== 
==16450== 
==16450== Process terminating with default action of signal 11 (SIGSEGV)
==16450==  Bad permissions for mapped region at address 0x0
==16450==at 0x0: ???
==16450==by 0x4224167: ???
==16450==by 0x4024537: ???
==16450==by 0x5833A3F: ???
==16450== Jump to the invalid address stated on the next line
==16450==at 0x0: ???
==16450==by 0x42239D7: ??? (in /lib/x86_64-linux-gnu/ld-2.24.so)
==16450==by 0x4025477: ???
==16450==by 0x5833A3F: ???
==16450==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
==16450== 
==16450== 
==16450== Process terminating with default action of signal 11 (SIGSEGV)
==16450==  Bad permissions for mapped region at address 0x0
==16450==at 0x0: ???
==16450==by 0x42239D7: ??? (in /lib/x86_64-linux-gnu/ld-2.24.so)
==16450==by 0x4025477: ???
==16450==by 0x5833A3F: ???

I'll have to try this on a distribution with better debugging
information.



Bug#595790: [Pkg-zfsonlinux-devel] Bug#595790: hostid: useless unless fixed

2016-09-28 Thread Florian Weimer
* Petter Reinholdtsen:

> [Florian Weimer]
>> That's not very different from /etc/machine-id, isn't it?
>
> Ah, thank you very much for bringing this systemd setting to my
> attention.  I was not aware of it.
>
> I agree that it seem very similar in purpose and implementation.  Will
> it be available on non-linux Debian architectures too?

It might be possible to port over this part, yes.

>>> We need to figure out how to transform the UUID to a 32 bit integer,
>>> of course.
>>
>> And I think this is the crux of the problem.  Whatever we do, with
>> today's cluster sizes it's just not reliably unique.
>
> Well, for the set of machines we have available at work (ca. 3000) it
> would be sufficiently unique.

I simulated 100,000 random assigns of 32-bit host IDs to 3,000 hosts,
and got collisions in 104 cases.

For 5,000 hosts, I got 286, and for 10,000, 1,112 (again in 100,000
runs).  I was lazy, it shouldn't be too hard to calculate expected
values accurately.

So a 32-bit value without central coordination is pretty much a time
bomb.

> For most sites it would make the return value from gethostid()
> unique.

The IP address of a host could be better than that.  I doubt it is
possible to imrpove upon the glibc implementation.

>> DMI data seems risky because it depends on firmware, and there are so
>> many firmware bugs out there.
>
> I did not quite understand what you mean here.  Do you mean the DMI
> value in your experience isn't unique?

I wouldn't count on them being unique.  Most such ID fields are
definitely not, and there are groups out there who strongly oppose
device IDs.



Bug#595790: [Pkg-zfsonlinux-devel] Bug#595790: hostid: useless unless fixed

2016-09-28 Thread Florian Weimer
* Petter Reinholdtsen:

> Something like this should work, I guess:
> 
> if [ ! -f /etc/hostid ]; then
>if [ -e /sys/class/dmi/id/product_uuid ]; then
>sethostidfromuuid $(cat /sys/class/dmi/id/product_uuid)
>else
>   dd if=/dev/urandom bs=1 count=4 of=/etc/hostid 2>/dev/null
>fi
> fi

That's not very different from /etc/machine-id, isn't it?

> We need to figure out how to transform the UUID to a 32 bit integer,
> of course.

And I think this is the crux of the problem.  Whatever we do, with
today's cluster sizes it's just not reliably unique.

You could use /etc/machine-id instead.  Some effort goes into that to
make it actually unique.

DMI data seems risky because it depends on firmware, and there are so
many firmware bugs out there.  It would also not address the matter of
changing host IDs as the result of host migrations.



Bug#838913: libc6: There's probably a bug in libpthread, affecting several user programs.

2016-09-27 Thread Florian Weimer
* Aurelien Jarno:

> On 2016-09-27 13:44, Florian Weimer wrote:
>> * Aurelien Jarno:
>> 
>> > Hmm, rsync doesn't use libpthread, so that clearly rules out a
>> > libpthread issue. That said, all the example you gave fail to allocate
>> > the memory correctly, either through malloc (glibc) or mmap (kernel)
>> > which returns -ENOMEM. This points to either a kernel issue, or a
>> > limitation of the memory using for example ulimit.
>> 
>> The mm subsystem in the 4.7 upstream kernel has a very visible issue
>> which causes allocation failures:
>> 
>>   <http://marc.info/?l=linux-mm=147422898523307>
>>
>> There are other threads as well.  (I personally see this with the
>> xfs_inode cache.)
>> 
>> Usually it manifests in premature OOM killer invocations, but maybe
>> something the reporter's system configuration changes that (perhaps it
>> runs with vm.overcommit_memory=2?).
>  
> Indeed, that is correct. The problem has been fixed in version 4.7.5,
> while the reporter seems to run version 4.7.4. Upgrading to the latest
> kernel version would be a good start.

I don't think this has been fully fixed in 4.7.5.  I'm running that
version now, and with lots of xfs_inode objects, I observe basically
zero read-ahead, which results in stuttering media playback with
ogg123.  vm.drop_caches=3 makes the stuttgering go away.

I need to see if I can still reproduce the OOMs.  This was a bit
tricky before.



Bug#838913: libc6: There's probably a bug in libpthread, affecting several user programs.

2016-09-27 Thread Florian Weimer
* Fernando Santagata:

>> Usually it manifests in premature OOM killer invocations, but maybe
>> something the reporter's system configuration changes that (perhaps it
>> runs with vm.overcommit_memory=2?).
>
> That's it. I found this in /var/log/kern.log at the time I run a program
> that crashed:
>
> Sep 27 10:37:31 gretux kernel: [ 77.250470] mmap: moar (2564): VmData
> 135217152 exceed data ulimit 134217728. Update limits or use boot
> option ignore_rlimit_data.

No, I think the above is unrelated.  It relates to a userspace ABI
break related to the RLIMIT_DATA implementation.



Bug#838913: libc6: There's probably a bug in libpthread, affecting several user programs.

2016-09-27 Thread Florian Weimer
* Aurelien Jarno:

> Hmm, rsync doesn't use libpthread, so that clearly rules out a
> libpthread issue. That said, all the example you gave fail to allocate
> the memory correctly, either through malloc (glibc) or mmap (kernel)
> which returns -ENOMEM. This points to either a kernel issue, or a
> limitation of the memory using for example ulimit.

The mm subsystem in the 4.7 upstream kernel has a very visible issue
which causes allocation failures:

  

There are other threads as well.  (I personally see this with the
xfs_inode cache.)

Usually it manifests in premature OOM killer invocations, but maybe
something the reporter's system configuration changes that (perhaps it
runs with vm.overcommit_memory=2?).



Bug#838913: libc6: There's probably a bug in libpthread, affecting several user programs.

2016-09-26 Thread Florian Weimer
* Fernando Santagata:

> One month ago everything worked fine on my Debian sid computer.
> After an update/dist-upgrade cycle in which libc6 was updated I
> started noticing some malfunctions.

Did you upgrade the kernel at the same time?



Bug#824429: libc6: In certain locale combinations mbsrtowcs cannot recover from EILSEQ

2016-09-18 Thread Florian Weimer
tags 824429 upstream
forwarded 824429 https://sourceware.org/bugzilla/show_bug.cgi?id=20617
thanks

* Christoph Biedl:

> It might be questionable whether this is a bug in glibc at all. But at
> least it's surprising behaviour.
>
> The reproducer below calls mbstowcs two times, first time with
> an illegal UTF-8 sequence, second time a correct one.
>
> Now if the caller's environment is set to something UTF-8-ish like
> "en_US.UTF-8" or "de_DE.UTF-8", also the second and any further
> mbsrtowcs invocation fail with EILSEQ. Note setting LC_CTYPE to an
> empty string is also required to make this happen.

POSIX and C11 explicitly say that the conversion state is undefined
after EILSEQ.  There does not appear to be a way to reset the internal
(global) conversion state used by mbsrtowcs, so a NULL argument for
the conversion state pointer is rarely useful.  We should probably add
a warning in glibc for that case.

Filed upstream: https://sourceware.org/bugzilla/show_bug.cgi?id=20617



Bug#783210: [PATCH] nscd_stat.c: make the build reproducible

2016-07-28 Thread Florian Weimer

On 03/09/2016 05:30 PM, Mike Frysinger wrote:


would it be so terrible to properly marshall this data ?


Ximin Luo and I discussed this and I wonder if it is possible to read 
out the libc.so.6 build ID if it is present.  It should indirectly call 
all the layout dependencies and be reasonably easy to access because it 
is in an allocated section (and we might want to print it from an 
libc.so.6 invocation, too).


We still need the time-based approach if the build ID is not available, 
but I expect most distributions will have something like it.


The Debian bug is:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=783210

(Also Cc:ed)

Florian



Bug#815974: Segmentation fault in libresolv triggered by php5-fpm

2016-03-01 Thread Florian Weimer
* Aurelien Jarno:

> On 2016-02-26 13:31, Carlos O'Donell wrote:
>> On Fri, Feb 26, 2016 at 7:46 AM, Fabian Niepelt  
>> wrote:
>> > This is the correct output, the older one contains a test I thought was
>> > in an endless loop but succeeded after a few minutes.
>> 
>> The glibc maintainers for debian need to review those failures. They
>> indicate serious deviation from expected behaviour. At the very least
>> the bug 18665* tests should not fail. However, the tests are sensitive
>> to response order.
>> 
>> -address: STREAM/TCP 10.0.3.6 80
>> -address: STREAM/TCP 2001:db8::4:6 80
>> +error: Name or service not known
>> 
>> This is a weird failure.
>
> The failures in this testsuite do not pass due to the patch we have that
> dynamically reloads /etc/resolv.conf when it changes. Just after the
> fake servers have been initialized, our libc reloads the configuration
> from /etc/resolv.conf, and thus the tests fail. Once removing the
> corresponding patch the tests pass, at least on my system.

Correct, the version Carlos posted does not have the compensation I
added for that, sorry.  I added this after the call to res_init in
resolv_redirect:

  /* Debian's local-dynamic-resolvconf.diff breaks name server
 overrides by application code.  The following triggers lazy
 initialization of the /etc/resolv.conf mtime value because
 res_mkquery calls __res_maybe_init internally.  Subsequent calls
 to this function will not try reload /etc/resolv.conf as a
 result.  */
  {
unsigned char query[512];
if (res_mkquery (QUERY, "query.example", C_IN, T_A,
 NULL, 0, NULL,
 query, sizeof (query)) < 0)
  {
printf ("error: res_mkquery: %m\n");
abort ();
  }
  }


> IMHO making sure that programs are restarted after applying the security
> update should be enough, but I am not fully sure about my analysis, so a
> confirmation would be nice to have.

This report 
is about an incomplete chroot update.  See comment 4 in particular
(although I wrote it without access to the actual installation).



Bug#802256: Backport tls_dtor_list hardening

2015-10-18 Thread Florian Weimer
Package: libc6
Version: 2.19-18+deb8u1

Please backport this upstream hardening patch to jessie (wheezy does
not have this feature yet):

  https://sourceware.org/bugzilla/show_bug.cgi?id=19018
  
https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=f586e1328681b400078c995a0bb6ad301ef73549

Also recommended for testing purposes:

  
https://sourceware.org/git/gitweb.cgi?p=glibc.git;a=commit;h=99e1dc0a688d6c25d3f422bc9f3fa29adb483339

Thanks,
Florian



Bug#717544: CVE-2013-2207: Remove pt_chown

2015-08-23 Thread Florian Weimer
* Samuel Thibault:

 Hello,

 Florian Weimer, le Thu 06 Aug 2015 07:15:01 +0200, a écrit :
 retitle 717544 CVE-2013-2207: Remove pt_chown
 thanks
 
 Can we please make another attempt at removing pt_chown, either
 completely or by removing the SUID bit?

 On linux ports only, please, kfreebsd and hurd still need it.  Removing
 pt_chown breaks 'screen' for instance.

Noted.

I really want to make this change, though, and push it to
stable/oldstable eventually.  What needs to happen for that?



Bug#717544: CVE-2013-2207: Remove pt_chown

2015-08-05 Thread Florian Weimer
retitle 717544 CVE-2013-2207: Remove pt_chown
thanks

Can we please make another attempt at removing pt_chown, either
completely or by removing the SUID bit?  The current devpts file
system is set up in such a way that this is not necessary.  Fedora and
Red Hat Enterprise Linux 7 already ship without pt_chown, apparently
without ill effects.  The Debian software I have checked sets up
/dev/pts with the gid=5 option, which means that pt_chown should be
unnecessary as well.

We also need to get this change into stable, maybe even oldstable.


-- 
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87lhdpf162@mid.deneb.enyo.de



Security-related patches for wheezy (and squeeze LTS)

2014-08-31 Thread Florian Weimer
I would like to send a few security-related backports frpm upstream
your way.  On the security side, we won't do a DSA for any of those
(probably; I still haven't got a complete handle on what's missing).
But it's certainly wheezy-updates material.

Should I just send the patches, or do you want diffs against the
repository?

Can we maintain the LTS versions in your Subversion repository, too?


-- 
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/874mwsze75@mid.deneb.enyo.de



Bug#679828: libc6: No easy way of enabling DNSSEC validation aka RES_USE_DNSSEC

2012-07-02 Thread Florian Weimer
* Matthew Grant:

 From my investigations this can only be enabled by recompiling each bit
 of software to set the RES_USE_DNSSEC flag in _res.options, as well as
 RES_USE_EDNS0. (Please see racoon bug #679483).  The enablement method
 is from openssh 6.0p1, openbsd-compat/getrrsetbyname.c 

This does not actually activate DNSSEC, it just tells the recursive
resolver that the application is able to process DNSSEC records.  The
application would still have to validate them.

Applications should never need to set the RES_USE_DNSSEC flag because
it does not make sense to treat DNSSEC-signed data differently from
unsigned data.

 Please create a resolv.conf flag so that RES_USE_DNSSEC is available
 to the systems administrator, and maybe a debconf screen to select it.

This alone wouldn't make any difference to the spoofing problem.

libc is not the correct place to put DNSSEC validation because many
processes are shortlived and would have to fetch all key material and
signatures from DNS, beginning at the root.  This would turn a single
name resolution into six or more DNS queries, which is excessive.

At this stage, you should run a BIND or Unbound process restricted to
localhost which performs the validation.  This validation will happen
even for applications which do not set the RES_USE_DNSSEC flag.



-- 
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87sjdau1uj@mid.deneb.enyo.de



Bug#609756: vsnprintf segfaults on second attempt with alloca

2011-01-12 Thread Florian Weimer
* Andrew Buckeridge:

 int vfprint(int fdout, const char *fmt, va_list ap)
 {
   int i=NONSTDBUF;
   i=vfnprint(fdout, i, fmt, ap);
   if(i-1)
   i=vfnprint(fdout, 1-i, fmt, ap);
   return i;
 }

va_copy seems to be missing here.

-- 
Florian Weimerfwei...@bfk.de
BFK edv-consulting GmbH   http://www.bfk.de/
Kriegsstraße 100  tel: +49-721-96201-1
D-76133 Karlsruhe fax: +49-721-96201-99



--
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/82k4ias9vi@mid.bfk.de



Bug#609756: vsnprintf segfaults on second attempt with alloca

2011-01-12 Thread Florian Weimer
* Andrew Buckeridge:

 C99 only va_copy does help. This is a new one for me.
 Does vfnprint destroy the callers ap?

Yes, it does.  Not on all platforms, but on amd64, for example.
Passing va_list as an argument does not make a sufficiently deep copy,
so that va_arg in the callee affects subsequent va_arg invocations in
the caller.

 Does this break C89 and C90?

Some systems have got __va_copy.  There's probably an autoconf test
for this.

-- 
Florian Weimerfwei...@bfk.de
BFK edv-consulting GmbH   http://www.bfk.de/
Kriegsstraße 100  tel: +49-721-96201-1
D-76133 Karlsruhe fax: +49-721-96201-99



--
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/8262tum25o@mid.bfk.de



squeeze upload for eglibc due to DSA-2122-2

2011-01-11 Thread Florian Weimer
I would like to make an upload of eglibc to address DSA-2122-2 (the
first round of patches for the $ORIGIN/LD_AUDIT issue does not cover
all corner cases, unfortunately).  The changes match those in
2.7-18lenny7, which are based almost verbatim on the upstream patches
(except for whitespace changes and one manual conflict resultion, see
the attachments; cvs-origin-suid.diff and
any/local-audit-pathless.diff).

Should I push this through testing-security, testing-proposed-updates
or unstable?  Have you got any preferences about version numbers?
commit 22cd1c9bcf57c5829d65b6da825f7a459d40c9eb
Author: Andreas Schwab sch...@redhat.com
Date:   Sun Oct 24 20:40:14 2010 -0400

Don't expand DST twice in dl_open

diff --git a/elf/dl-open.c b/elf/dl-open.c
index 754a263..c394b3f 100644
--- a/elf/dl-open.c
+++ b/elf/dl-open.c
@@ -221,36 +221,6 @@ dl_open_worker (void *a)
 
   assert (_dl_debug_initialize (0, args-nsid)-r_state == RT_CONSISTENT);
 
-  /* Maybe we have to expand a DST.  */
-  if (__builtin_expect (dst != NULL, 0))
-{
-  size_t len = strlen (file);
-  size_t required;
-  char *new_file;
-
-  /* Determine how much space we need.  We have to allocate the
-	 memory locally.  */
-  required = DL_DST_REQUIRED (call_map, file, len, _dl_dst_count (dst, 0));
-
-  /* Get space for the new file name.  */
-  new_file = (char *) alloca (required + 1);
-
-  /* Generate the new file name.  */
-  _dl_dst_substitute (call_map, file, new_file, 0);
-
-  /* If the substitution failed don't try to load.  */
-  if (*new_file == '\0')
-	_dl_signal_error (0, dlopen, NULL,
-			  N_(empty dynamic string token substitution));
-
-  /* Now we have a new file name.  */
-  file = new_file;
-
-  /* It does not matter whether call_map is set even if we
-	 computed it only because of the DST.  Since the path contains
-	 a slash the value is not used.  See dl-load.c.  */
-}
-
   /* Load the named object.  */
   struct link_map *new;
   args-map = new = _dl_map_object (call_map, file, 0, lt_loaded, 0,
commit 96611391ad8823ba58405325d78cefeae5cdf699
Author: Andreas Schwab sch...@redhat.com
Date:   Thu Dec 9 15:00:59 2010 +0100

Ignore origin of privileged program

diff --git a/elf/dl-object.c b/elf/dl-object.c
index 5d15ce1..a34e902 100644
--- a/elf/dl-object.c
+++ b/elf/dl-object.c
@@ -220,6 +220,9 @@ _dl_new_object (char *realname, const char *libname, int type,
 out:
   new-l_origin = origin;
 }
+  else if (INTUSE(__libc_enable_secure)  type == lt_executable)
+/* The origin of a privileged program cannot be trusted.  */
+new-l_origin = (char *) -1;
 
   return new;
 }
commit 8e9f92e9d5d7737afdacf79b76d98c4c42980508
Author: Andreas Schwab sch...@redhat.com
Date:   Sun Oct 24 21:43:15 2010 -0400

Require suid bit on audit objects in privileged programs

diff --git a/elf/dl-deps.c b/elf/dl-deps.c
index a58de5c..a51fb6e 100644
--- a/elf/dl-deps.c
+++ b/elf/dl-deps.c
@@ -62,7 +62,7 @@ openaux (void *a)
 {
   struct openaux_args *args = (struct openaux_args *) a;
 
-  args-aux = _dl_map_object (args-map, args-name, 0,
+  args-aux = _dl_map_object (args-map, args-name,
 			  (args-map-l_type == lt_executable
 			   ? lt_library : args-map-l_type),
 			  args-trace_mode, args-open_mode,
diff --git a/elf/dl-load.c b/elf/dl-load.c
index a7162eb..aa8738f 100644
--- a/elf/dl-load.c
+++ b/elf/dl-load.c
@@ -1812,7 +1812,7 @@ open_verify (const char *name, struct filebuf *fbp, struct link_map *loader,
if MAY_FREE_DIRS is true.  */
 
 static int
-open_path (const char *name, size_t namelen, int preloaded,
+open_path (const char *name, size_t namelen, int secure,
 	   struct r_search_path_struct *sps, char **realname,
 	   struct filebuf *fbp, struct link_map *loader, int whatcode,
 	   bool *found_other_class)
@@ -1894,7 +1894,7 @@ open_path (const char *name, size_t namelen, int preloaded,
 	  /* Remember whether we found any existing directory.  */
 	  here_any |= this_dir-status[cnt] != nonexisting;
 
-	  if (fd != -1  __builtin_expect (preloaded, 0)
+	  if (fd != -1  __builtin_expect (secure, 0)
 	   INTUSE(__libc_enable_secure))
 	{
 	  /* This is an extra security effort to make sure nobody can
@@ -1963,7 +1963,7 @@ open_path (const char *name, size_t namelen, int preloaded,
 
 struct link_map *
 internal_function
-_dl_map_object (struct link_map *loader, const char *name, int preloaded,
+_dl_map_object (struct link_map *loader, const char *name,
 		int type, int trace_mode, int mode, Lmid_t nsid)
 {
   int fd;
@@ -2067,7 +2067,8 @@ _dl_map_object (struct link_map *loader, const char *name, int preloaded,
 	  for (l = loader; l; l = l-l_loader)
 	if (cache_rpath (l, l-l_rpath_dirs, DT_RPATH, RPATH))
 	  {
-		fd = open_path (name, namelen, preloaded, l-l_rpath_dirs,
+		fd = open_path (name, namelen, mode  __RTLD_SECURE,
+l-l_rpath_dirs,
 realname, fb, loader, LA_SER_RUNPATH,
 found_other_class);
 		if 

Bug#600667: eglibc: cve-2010-3847 dynamic linker expands $ORIGIN in setuid library search path

2010-10-22 Thread Florian Weimer
* Aurelien Jarno:

 I have just committed the fix, I am planning to do an upload soon to
 unstable. Do you think we should also fix it in stable? via a security
 release?

FYI, I have uploaded eglibc 2.11.2-6+squeeze1 to testing-security.



-- 
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87vd4usmme@mid.deneb.enyo.de



Re: glibc_2.7-18lenny6_source.changes REJECTED

2010-10-22 Thread Florian Weimer
* Debian FTP Masters:

 Reject Reasons:
 source only uploads are not supported.

 Notes:
 Mapping stable-security to proposed-updates.

Ahem.  Should I upload a newer version to stable-proposed-updates, or
is this a spurious error message?


-- 
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87sjzyruss@mid.deneb.enyo.de



Bug#568913: depends on nonexistent glibc-2.11-1

2010-02-10 Thread Florian Weimer
 Package: locales

 Now there are TWO experimental packages.
 # apt-cache policy locales
 locales:
   Installed: 2.10.2-5
   Candidate: 2.11-0exp4
   Version table:
  2.11-0exp4 0
 990 http://ftp.tw.debian.org experimental/main Packages
  2.11-0exp2 0
 990 http://ftp.tw.debian.org experimental/main Packages
  *** 2.10.2-5 0
 500 http://ftp.tw.debian.org unstable/main Packages
 100 /var/lib/dpkg/status

 However both depend on nonexistent glibc-2.11-1.

Experimental hasn't got full autobuilder support.  You see such bogus
Architecture: all packages if the source package hasn't been built for
your architecture.  (Presumably, things could be improved on the dak
side. to skip such packages when compiling the Packages file.)

Note that this should not cause problems in practice because APT will
not install from experimental automatically (hence the three starts
before version 2.10.2-5).



-- 
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#519774: libc6: causes many programs not to be able to resolve dns addresses

2009-03-17 Thread Florian Weimer
* Mark Kamichoff:

 Hi - 

 The problem is that the DNS server of your ISP does not conform to the
 RFC and only answer to the  query with a void answer. It never
 answer to the A query, so the glibc resolver can only conclude the
 whole query has no answer.

 Just a thought, many DNS ALGs on firewalls (eg, Juniper NetScreen) will
 close the UDP/53 session after one packet (response, presumably) is
 received, and drop any subsequent response packets.

This will break other clients, too.  For instance, a BIND forwarder
without source port randomization, who happens to have multiple
queries in flight.

Has it been verified that the second DNS packet actually leaves the
box?  I think there was word of a kernel bug leading to dropped UDP
packets which might cause this.



-- 
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#382175: Sun RPC libraries and other stories

2008-11-18 Thread Florian Weimer
* Simon Phipps:

 On Nov 5, 2008, at 23:23, Michael Banck wrote:

 - portmap.c

 /*
 @(#)portmap.c   2.3 88/08/11 4.0 RPCSRC
 static char sccsid[] = @(#)portmap.c 1.32 87/08/06 Copyr 1984 Sun
 Micro;
 */

 This is portmap-6.0, from http://neil.brown.name/portmap/

 Is this in any way related to any Sun code, or is the string simply
 used by the author for external reference in some way?

It seems that the code was released by the Portable NFS group at Sun
in 1987:

  http://ftp.andrew.cmu.edu/pub//AUIS/src/contrib/mit/fxlib/rpc3.9/

(portmap.c is in etc.  Ah, those were the times!)

The distribution above was apparently intended for use on 4BSD.  This
might explain why it does not match a code base derived from SunOS 5.

An announcement of the release was re-posted to Usenet in a digest
with message ID [EMAIL PROTECTED].



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#382175: Sun RPC libraries and other stories

2008-11-18 Thread Florian Weimer
* Simon Phipps:

 On Nov 18, 2008, at 03:52, Ben Hutchings wrote:

 Many of the functions in portmap.c seem to correspond to
 rpcbind (usr/src/cmd/rpcbind) in OpenSolaris:

 Is it just the function prototypes that are derived, or is there
 derived source defining them too?

From our portmap.c:

| /*
|  * Stuff for the rmtcall service
|  */
| #define ARGSIZE 9000
|
| struct encap_parms {
| u_int arglen;
| char *args;
| };
|
| static bool_t
| xdr_encap_parms(XDR *xdrs, struct encap_parms *epp)
| {
|
| return (xdr_bytes(xdrs, (epp-args), (epp-arglen), ARGSIZE));
| }
|
| struct rmtcallargs {
| u_long  rmt_prog;
| u_long  rmt_vers;
| u_long  rmt_port;
| u_long  rmt_proc;
| struct encap_parms rmt_args;
| };
|
| static bool_t
| xdr_rmtcall_args(XDR *xdrs, struct rmtcallargs *cap)
| {
|
| /* does not get a port number */
| if (xdr_u_long(xdrs, (cap-rmt_prog)) 
| xdr_u_long(xdrs, (cap-rmt_vers)) 
| xdr_u_long(xdrs, (cap-rmt_proc))) {
| return (xdr_encap_parms(xdrs, (cap-rmt_args)));
| }
| return (FALSE);
| }
|
| static bool_t
| xdr_rmtcall_result(XDR *xdrs, struct rmtcallargs *cap)
| {
| if (xdr_u_long(xdrs, (cap-rmt_port)))
| return (xdr_encap_parms(xdrs, (cap-rmt_args)));
| return (FALSE);
| }
| 
| /*
|  * only worries about the struct encap_parms part of struct rmtcallargs.
|  * The arglen must already be set!!
|  */
| static bool_t
| xdr_opaque_parms(XDR *xdrs, struct rmtcallargs *cap)
| {
| 
| return (xdr_opaque(xdrs, cap-rmt_args.args, cap-rmt_args.arglen));
| }

From 
http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/cmd/rpcbind/rpcb_svc_com.c:

| /*
|  * Stuff for the rmtcall service
|  */
| struct encap_parms {
|   ulong_t arglen;
|   char *args;
| };
|
| static bool_t
| xdr_encap_parms(xdrs, epp)
|   XDR *xdrs;
|   struct encap_parms *epp;
| {
|   return (xdr_bytes(xdrs, (epp-args), (uint_t *)(epp-arglen), ~0));
| }
|
|
| struct r_rmtcall_args {
|   ulong_t rmt_prog;
|   ulong_t rmt_vers;
|   ulong_t rmt_proc;
|   int rmt_localvers;  /* whether to send port # or uaddr */
|   char*rmt_uaddr;
|   struct encap_parms rmt_args;
| };
|
| /*
|  * XDR remote call arguments.  It ignores the address part.
|  * written for XDR_DECODE direction only
|  */
| static bool_t
| xdr_rmtcall_args(xdrs, cap)
|   register XDR *xdrs;
|   register struct r_rmtcall_args *cap;
| {
|   /* does not get the address or the arguments */
|   if (xdr_u_long(xdrs, (cap-rmt_prog)) 
|   xdr_u_long(xdrs, (cap-rmt_vers)) 
|   xdr_u_long(xdrs, (cap-rmt_proc))) {
|   return (xdr_encap_parms(xdrs, (cap-rmt_args)));
|   }
|   return (FALSE);
| }
|
| /*
|  * XDR remote call results along with the address.  Ignore
|  * program number, version  number and proc number.
|  * Written for XDR_ENCODE direction only.
|  */
| static bool_t
| xdr_rmtcall_result(xdrs, cap)
|   register XDR *xdrs;
|   register struct r_rmtcall_args *cap;
| {
|   bool_t result;
|
| #ifdef PORTMAP
|   if (cap-rmt_localvers == PMAPVERS) {
|   int h1, h2, h3, h4, p1, p2;
|   ulong_t port;
|
|   /* interpret the universal address for TCP/IP */
|   if (sscanf(cap-rmt_uaddr, %d.%d.%d.%d.%d.%d,
|   h1, h2, h3, h4, p1, p2) != 6)
|   return (FALSE);
|   port = ((p1  0xff)  8) + (p2  0xff);
|   result = xdr_u_long(xdrs, port);
|   } else
| #endif
|   if ((cap-rmt_localvers == RPCBVERS) ||
|   (cap-rmt_localvers == RPCBVERS4)) {
|   result = xdr_wrapstring(xdrs, (cap-rmt_uaddr));
|   } else {
|   return (FALSE);
|   }
|   if (result == TRUE)
|   return (xdr_encap_parms(xdrs, (cap-rmt_args)));
|   return (FALSE);
| }
| 
| /*
|  * only worries about the struct encap_parms part of struct r_rmtcall_args.
|  * The arglen must already be set!!
|  */
| static bool_t
| xdr_opaque_parms(xdrs, cap)
|   XDR *xdrs;
|   struct r_rmtcall_args *cap;
| {
|   return (xdr_opaque(xdrs, cap-rmt_args.args, cap-rmt_args.arglen));
| }

So there's certainly some overlap, and it's not just prototypes.



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#491809: libc6: DNS spoofing vulnerability [CVE-2008-1447]

2008-07-25 Thread Florian Weimer
reopen 491809
thanks

* Pierre Habouzit:

   Kaminsky agrees confirm the issue, so I can say for sure that the
 glibc isn't vulnerable to the attack he describes, as it needs a
 resolver that caches additionnal RRs, which the glibc doesn't do.

   As of attacks that would use non randomized source port use, this is
 addressed by recent kernels hence is fixed enough.

I've trouble parsing what you wrote.

Based on information provided at the DNS summit, I do think we should
harden the glibc stub resolver.



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#491809: libc6: DNS spoofing vulnerability [CVE-2008-1447]

2008-07-22 Thread Florian Weimer
* brian m. carlson:

 The glibc stub resolver is vulnerable to CVE-2008-1447, according to DSA
 1605.  Since the vast majority of network-using programs use glibc as a
 resolver, this vulnerability affects virtually any network-using
 program, hence the severity.  libc6 should not be released without a fix
 for this problem.

 The vulnerability has been exposed:

 http://demosthen.es/post/43048623/reliable-dns-forgery-in-2008

I fail to see how this attack has a chance to work against non-caching
stub resolvers like the GNU libc resolver.

However, we're working on a solution.



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



  1   2   >