Adhemerval Zanella | 20 May 16:10 2015

[PATCH] Remove socket.S implementation

Hi

This patch is another of the required adjustments for the fix for bz12683
(Race conditions in pthread cancellation) and the idea is to get rid of
assembly implementation for socket function for ports which uses socketcall.

This patch removes the socket.S implementation for all ports and replace
it by a C implementation using socketcall where it is required.  For ports
that implement the syscall directly, there is no change.

The patch idea is to simplify the socket function implementation that
uses the socketcall to be based on C implemetation instead of a pseudo
assembly implementation with arch specific parts.  All the affect
architectures (i386, microblaze, mips, powerpc, and sparc) have support
for 6 argument syscalls.

I have cross-build GLIBC for afore-mentioned ports and tested on i386,
x86_64, powerpc64le, arm, and aarch64.

--

	* nptl/Makefile (CFLAGS-accept.c): Add -fexceptions and
	-fasynchronous-unwind-tables.
	(CFLAGS-sendto.c): Likewise.
	(CFLAGS-sendmsg.c): Likewise.
	(CFLAGS-connect.c): Likewise.
	(CFLAGS-recvmsg.c): Likewise.
	(CFLAGS-recvfrom.c): Likewise.
	* sysdeps/unix/sysv/linux/socketcall.h (SOCKOP_invalid): Define.
	(SOCKETCALL): New macro: non-cancellable socketcall.
(Continue reading)

Adhemerval Zanella | 20 May 16:10 2015

[PATCH] Use inline syscalls for non-cancellable versions

Hi

This patch is one of the required adjustments for the fix for bz12683
(Race conditions in pthread cancellation) and the idea is to not rely
on the non-cancelable entry points for cancelable syscalls (since the
upcoming fill will remove them).

This patch uses inline calls (through INLINE_SYSCALL macro) to define
the non-cancellable functions macros to avoid use of the
syscall_nocancel entrypoint.

Tested on i386, x86_64, x32, powerpc32, powerpc64, arm, and aarch64.

---

	* sysdeps/unix/sysv/linux/not-cancel.h (open_not_cancel): Rewrite to
	be an inline implementation regardless of library is built within.
	(open_not_cancel_2): Likewise.
	(__read_nocancel): Likewise.
	(__write_nocancel): Likewise.
	(openat_not_cancel): Likewise.
	(openat_not_cancel_3): Likewise.
	(openat64_not_cancel): Likewise.
	(openat64_not_cancel_3): Likewise.
	(__close_nocancel): Likewise.
	(pause_not_cancel): Likewise.
	(nanosleep_not_cancel): Likewise.
	(sigsuspend_not_cancel): Likewise.

--
(Continue reading)

Ramana | 19 May 08:20 2015
Picon

[Ping] Errors with make check of glibc v2.20 while cross compiling for powerpc

On Wed, Apr 1, 2015 at 12:03 PM, Ramana <ramana.venkat83@...> wrote:
> Hi,
>
> Probably the query
> https://sourceware.org/ml/libc-alpha/2015-03/msg00841.html posted on
> libc-alpha is more relavent here.
>
> Thank you,
> Venkata Ramanaiah N

Patrick Donnelly | 16 May 00:04 2015

runtime loader replaces argv[0]

Hi,

My colleagues and I are using the runtime loader in preservation
software for scientific applications. To be specific, we preserve the
runtime loader implicitly used by the software so that it can be run
again in the future, possibly on a completely different platform (but
using the same or newer kernel). In this context, we are using Linux
but the problems exists for all kernels.

The problem we see is that the glibc loader unconditionally replaces
argv[0]. So if I want to run an application on a different platform
that uses a different loader, I would do this instead:

execve("./preserved/ld-linux.so", ["argv[0]" /* from original
experiment */, "./preserved/application.exe" /* physical exe */,
"argv[1]", ...], [...]);

I would expect the loader to simply strip off its argv[1] and leave
the rest alone. Unfortunately, it sets argv[0] to argv[1], as if we
ran:

execve("./preserved/application.exe", ["./preserved/application.exe",
"argv[1]", ...], [...]);

This prevents us from passing the original argv[0] to the application.
I have attached two C programs that exhibit the problem.

Ironically enough, the software that is most affected by this is the
loader itself. If argv[0] is not a real path (i.e. beginning with ./
or /), then it will readlink("/proc/self/exe") to determine the
(Continue reading)

Brian J. Murrell | 10 May 03:28 2015
Picon

nftw: No such file or directory after changing file's links

Hi,

I have a program which use nftw() to descend a file tree.  As it's
walking downward, it's looking for identical files in a parallel tree.
When it comes across an identical file in the parallel tree, it removes
it and then creates a link from the tree that is being walked into the
parallel tree.

Yes, I am saving space between two file trees that have many identical
files by creating links between them.

But what I am finding is that after I have created the link, when my
"fn()" returns nftw() fails out with a "No such file or directory".

I suppose it has something to do with modifying the directory that
nftw() is currently processing by adding to the link counts of files in
the directory being processed.

But what is the solution?

Cheers,
b.

David Aldrich | 8 May 12:53 2015
Picon

How to track the status of a patch?

Hi

I am interested in this patch:

http://patchwork.sourceware.org/patch/5341/

How can I track the status of this patch (i.e. find out whether it will be included in a future libc release) ?

Best regards

David

Justin | 4 May 06:43 2015
Picon

build issue

armv7l-unknown-linux-gnueabihf-gcc 
-Wl,-O1,--sort-common,--as-needed,-z,relro  -nostdlib -nostartfiles -r 
-o glibc-2.21/Build/elf/librtld.map.o '-Wl,-(' 
glibc-2.21/Build/elf/dl-allobjs.os glibc-2.21/Build/libc_pic.a -lgcc 
'-Wl,-)' -Wl,-Map,glibc-2.21/Build/elf/librtld.mapT
glibc-2.21/Build/libc_pic.a(init-first.os):(.data+0x0): multiple 
definition of `__libc_multiple_libcs'
glibc-2.21/Build/elf/dl-allobjs.os:(.bss+0x90): first defined here
glibc-2.21/Build/libc_pic.a(dl-addr.os): In function 
`_dl_addr_inside_object':
dl-addr.c:(.text+0x308): multiple definition of `_dl_addr_inside_object'
glibc-2.21/Build/elf/dl-allobjs.os:glibc-2.21/Build/elf/dl-tlsdesc.os:(.text+0x13e04): 
first defined here
glibc-2.21/Build/libc_pic.a(_itoa.os): In function `_itoa':
_itoa.c:(.text+0xb4): multiple definition of `_itoa'
glibc-2.21/Build/elf/dl-allobjs.os:glibc-2.21/Build/elf/dl-tlsdesc.os:(.text+0x172b0): 
first defined here
collect2: error: ld returned 1 exit status
Makefile:307: recipe for target 'glibc-2.21/Build/elf/librtld.map' failed
make[2]: *** [glibc-2.21/Build/elf/librtld.map] Error 1
make[2]: Leaving directory 'glibc-2.21/elf'
Makefile:213: recipe for target 'elf/subdir_lib' failed
make[1]: *** [elf/subdir_lib] Error 2
make[1]: Leaving directory 'glibc-2.21'
Makefile:9: recipe for target 'all' failed
make: *** [all] Error 2

Picon

Mtrace shows memory leak because of its own __cxa_atexit call

Hello,

I'm a noob here, but I've found a behaviour in mtrace that I found odd. 
If a certain number of atexit calls are placed before mtrace() is 
called, an additional memory allocation is registered and is reported as 
a leak by the auxiliary command line tool.

I found out that this happens because mtrace configures the malloc hooks 
before it calls __cxa_atexit, and this function may allocate memory for 
storing new function references. From what I understood by reading 
stdlib.h/cxa_atexit.c, __new_exitfn allocates space when registering the 
33rd function reference.

I created a simple test.c file (attached) to test it, and it seems to 
work if I perform 31 calls to atexit before calling mtrace().

I attempted to "fix" the problem by moving the order of operations in 
the mtrace function. I've attached a patch that only sets the hooks 
after the __cxa_atexit call. It seems to have solved my problem, but I'm 
unsure if there are other consequences I can't foresee.

Would this "fix" be acceptable, or would it be better if I worked around 
the problem in my client program. If a workaround is better, what would 
be a good approach? I'm thinking of perhaps calling mtrace() followed by 
muntrace() at the start of the program once to make sure the 
__cxa_atexit function is called, and consequently preventing the memory 
leak from appearing in future calls of mtrace().

Thanks in advance for any feedback,

(Continue reading)

Florian Weimer | 21 Apr 16:52 2015
Picon

Re: glibc 2.5 - patch for GHOST (CVE-2015-0235)

On 04/21/2015 04:47 PM, czezz wrote:
> Well, that was my initial idea.
> But as only I looked little bit deeper I realized I cannot go like that.
> Some of patches from your repository/link contain lines like following:
> glibc-rh947882.patch:diff -urN glibc-2.5-20061008T1257.orig/sysdeps/posix/getaddrinfo.c glibc-2.5-20061008T1257/sysdeps/posix/getaddrinfo.c
> glibc-rh947882.patch:--- glibc-2.5-20061008T1257.orig/sysdeps/posix/getaddrinfo.c      
2013-04-11 14:41:39.224166628 -0400
> glibc-rh947882.patch:+++ glibc-2.5-20061008T1257/sysdeps/posix/getaddrinfo.c    2013-04-11
15:30:32.186995962 -0400
> so, the script for building in your repository expects to have source files/some of source files in dir glibc-2.5-20061008T1257/
> where in Slackware's building script it is glibc-2.5/
> Of course I can re-tar and re-compress Slackware's source glibc but then I must modify all Slack's diff
files (which is in the end and idea).
> Im more worried that I have compared eg:
> glibc-rh645672.patch with glibc.CVE-2010-3856.diff.gz. They are similar but not identical...

Ah, I misunderstood you.  I assumed that you were attempting to backport
a single fix.  If you want to reach bug fix parity with a still-support
glibc (be it from Debian, Red Hat or SuSE), that is going to be a *lot*
more work.

--

-- 
Florian Weimer / Red Hat Product Security

Florian Weimer | 21 Apr 16:11 2015
Picon

Re: glibc 2.5 - patch for GHOST (CVE-2015-0235)

On 04/21/2015 04:08 PM, czezz wrote:

> I though that by replacing these patch list with the ones form you and also changing the source archive from
you I would make it...

No the only change you should make is to add yet another patch.  No
other changes.  Do not replace the tarball or remove the other patches.

--

-- 
Florian Weimer / Red Hat Product Security

Florian Weimer | 21 Apr 15:39 2015
Picon

Re: glibc 2.5 - patch for GHOST (CVE-2015-0235)

On 04/21/2015 03:27 PM, czezz wrote:
> Hi Florian,
> thank you for looking into this.
> I have removed and that did not help :/

Then it's a Slackware package build issue, and you need to ask on a
Slackware support list/forum for help, sorry.

--

-- 
Florian Weimer / Red Hat Product Security


Gmane