Re: /tmp/ecp.* created during kernel build?

[Ed Maste]

On 28 December 2016 at 06:31, Dimitry Andric  wrote:
>
> This looks like a minor bug in elfcopy, when used as objcopy,
> specifically when in combination with the --input-target binary flag:
>
> $ mkdir /tmp/foo
> $ export TMPDIR=/tmp/foo
> $ ls -l /tmp/foo/
> $ /usr/bin/objcopy --input-target binary --output-target elf64-x86-64-freebsd 
>  --binary-architecture i386  cloudabi32_vdso.o bar.o
> $ ls -l /tmp/foo
> total 12
> -rw-r--r--  1 dim  wheel  10198 2016-12-28 12:29:32 ecp.0xbNAi5i
>
> E.g. for some reason this does not clean up the temporary file.

This should be fixed as of r316284 and will be MFCd before 11.1.
___
freebsd-security@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"

Re: /tmp/ecp.* created during kernel build?

[Andre Albsmeier]

On Wed, 28-Dec-2016 at 12:31:49 +0100, Dimitry Andric wrote:
> On 28 Dec 2016, at 04:10, Roger Marquis  wrote:
> > 
> >> Found a couple of ecp binaries in /tmp, apparently created concurrent
> >> with an 11.0 x86_64 kernel build.  Anyone else seen this?  Could they
> >> be related to a "make buildkernel"?
> > 
> > Confirmed 'make buildkernel' does create these files, apparently via
> > /usr/src/contrib/elftoolchain/elfcopy/main.c (thanks Adam).
> > 
> > Still odd that these are LSB binaries which don't run on this server and
> > nothing including cleanworld removed them.  Anyone audited elftoolchain
> > recently?
> 
> This looks like a minor bug in elfcopy, when used as objcopy,
> specifically when in combination with the --input-target binary flag:
> 
> $ mkdir /tmp/foo
> $ export TMPDIR=/tmp/foo
> $ ls -l /tmp/foo/
> $ /usr/bin/objcopy --input-target binary --output-target elf64-x86-64-freebsd 
>  --binary-architecture i386  cloudabi32_vdso.o bar.o
> $ ls -l /tmp/foo
> total 12
> -rw-r--r--  1 dim  wheel  10198 2016-12-28 12:29:32 ecp.0xbNAi5i
> 
> E.g. for some reason this does not clean up the temporary file.

strip (objcopy) does more curious things:

$ cd /tmp
$ cp /usr/lib/libc.a .
$ strip --strip-debug libc.a
$ strip --strip-debug libc.a

[1]960 segmentation fault  strip --strip-debug libc.a

Interesting is also that libc.a grows(!):

Before the strip:
-r--r-  1 andre  wheel  2622684 24 Mar 13:18 libc.a

After:
-r--r-  1 andre  wheel  2713792 24 Mar 13:19 libc.a

-Andre


> 
> -Dimitry
> 



-- 
Never argue with an idiot. They drag you down to
their level, then beat you with their experience.
___
freebsd-security@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"

Re: /tmp/ecp.* created during kernel build?

[Dimitry Andric]

On 28 Dec 2016, at 04:10, Roger Marquis  wrote:
> 
>> Found a couple of ecp binaries in /tmp, apparently created concurrent
>> with an 11.0 x86_64 kernel build.  Anyone else seen this?  Could they
>> be related to a "make buildkernel"?
> 
> Confirmed 'make buildkernel' does create these files, apparently via
> /usr/src/contrib/elftoolchain/elfcopy/main.c (thanks Adam).
> 
> Still odd that these are LSB binaries which don't run on this server and
> nothing including cleanworld removed them.  Anyone audited elftoolchain
> recently?

This looks like a minor bug in elfcopy, when used as objcopy,
specifically when in combination with the --input-target binary flag:

$ mkdir /tmp/foo
$ export TMPDIR=/tmp/foo
$ ls -l /tmp/foo/
$ /usr/bin/objcopy --input-target binary --output-target elf64-x86-64-freebsd  
--binary-architecture i386  cloudabi32_vdso.o bar.o
$ ls -l /tmp/foo
total 12
-rw-r--r--  1 dim  wheel  10198 2016-12-28 12:29:32 ecp.0xbNAi5i

E.g. for some reason this does not clean up the temporary file.

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: /tmp/ecp.* created during kernel build?

[Roger Marquis]

Found a couple of ecp binaries in /tmp, apparently created concurrent
with an 11.0 x86_64 kernel build.  Anyone else seen this?  Could they
be related to a "make buildkernel"?


Confirmed 'make buildkernel' does create these files, apparently via
/usr/src/contrib/elftoolchain/elfcopy/main.c (thanks Adam).

Still odd that these are LSB binaries which don't run on this server and
nothing including cleanworld removed them.  Anyone audited elftoolchain
recently?

Roger
___
freebsd-security@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"

/tmp/ecp.* created during kernel build?

[Roger Marquis]

Found a couple of ecp binaries in /tmp, apparently created concurrent
with an 11.0 x86_64 kernel build.  Anyone else seen this?  Could they
be related to a "make buildkernel"?

# ls -l /tmp/ecp*
 -rw-r--r--   1 root  wheel  4229 Dec 27 06:21 ecp.Aak1ruL8
 -rw-r--r--   1 root  wheel  2371 Dec 27 06:21 ecp.8Wba0TzO

# file /tmp/ecp.*
 /tmp/ecp.8Wba0TzO: ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), not 
stripped
 /tmp/ecp.Aak1ruL8: ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), not 
stripped

# strings /tmp/ecp.Aak1ruL8
 belX
 __vdso_clock_gettime
 __vdso_getcpu
 __vdso_gettimeofday
 __vdso_time
 linux_platform
 linux_rt_sigcode
 linux_vdso.so.1
 LINUX_2.6
 x86_64
 .symtab
 .strtab
 .shstrtab
 .gnu.hash
 .dynsym
 .dynstr
 .gnu.version
 .gnu.version_d
 .eh_frame_hdr
 .eh_frame
 .dynamic
 .data
 .text
 .endrtsigcode
 .getip
 .startrtsigcode
 _DYNAMIC
 _GLOBAL_OFFSET_TABLE_
 clock_gettime
 LINUX_2.6
 __vdso_gettimeofday
 __vdso_getcpu
 gettimeofday
 time
 getcpu
 __vdso_clock_gettime
 linux_platform
 linux_rt_sigcode
 __vdso_time

# strings /tmp/ecp.8Wba0TzO
 linux32_rt_sigcode
 linux32_sigcode
 linux32_vsyscall
 linux_platform
 linux32_vdso.so.1
 LINUX_2.5
 i686
 .shstrtab
 .gnu.hash
 .dynsym
 .dynstr
 .gnu.version
 .gnu.version_d
 .eh_frame_hdr
 .eh_frame
 .dynamic
 .data
 .text

Is there anything else that might trace the origin of these files other
than possibly another buildkernel?

Thanks,
Roger
___
freebsd-security@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"