lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20070724220053.GA20531@deine-taler.de>
Date:	Wed, 25 Jul 2007 00:00:53 +0200
From:	Ulrich Kunitz <kune@...ne-taler.de>
To:	Chuck Ebbert <cebbert@...hat.com>
Cc:	"H. Peter Anvin" <hpa@...or.com>, linux-kernel@...r.kernel.org,
	honza@...os.cz, jkosina@...e.cz
Subject: Re: Is PIE randomization breaking klibc binaries?

On 07-07-24 16:57 Chuck Ebbert wrote:

> > $ strace ./cat
> > execve("./cat", ["./cat"], [/* 55 vars */]) = -1 ENOENT (No such file or directory)
> > ...

Chuck, my binaries run always into a segmentation violation. So
ENOENT is not the issue. (Notify it was on an x86-64.)

> > $ file cat
> > cat: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked (uses shared libs), stripped
> > 
> > Funny nobody noticed that before...
> > 
> 
> After installing klibc.so and klibc-<ID>.so into /lib everything works:
> 
> Program Headers:
>   Type           Offset   VirtAddr   PhysAddr   FileSiz  MemSiz   Flg Align
>   PHDR           0x000034 0x08048034 0x08048034 0x0000a0 0x0000a0 R E 0x4
>   INTERP         0x0000d4 0x080480d4 0x080480d4 0x00002a 0x00002a R   0x1
>         [Requesting program interpreter: /lib/klibc-58kBUyV_qhVvkMnaxy8A7N8rLak.so]
> 

Yes, these files were present in the initrd.img file. I checked it
by unpacking the initrd.img file. Notify also that I used
git-bisect to identify the PIE patch. This requires successful
builds. Reverting the patch clearly resolved the issue at the end.

> Ulrich, did your initrd contain the correct .so?

Sure! I have only one klibc-*.so on my box in /lib. I diffed the
file in the unpacked initrd.img with the file in /lib and there
has been no difference.

I always recreate the initial ramdisk after the kernel rebuild
with make install and my own installkernel script, which uses
mkinitramfs. The mkinitramfs script ensures that the klibc so
object from /lib and the klibc binaries from /usr/lib/klibc/bin
are copied into the initrd image. Usually that works without any
issue on x86, x86-64. PPC can't use make install, but I use
mkinitramfs there too, which handles klibc the same way.

> Did you try rebuilding klibc after building the new kernel?

Rebuilding klibc doesn't make sense from my point of view. What
should be the point of it?

-- 
Uli Kunitz
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ