Re: /tmp/ecp.* created during kernel build?
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?
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?
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?
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?
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"