daily CVS update output
Updating src tree: P src/distrib/sets/lists/man/mi P src/lib/libcurses/slk.c P src/share/man/man4/Makefile U src/share/man/man4/eqos.4 U src/share/man/man4/mcommphy.4 P src/sys/conf/Makefile.kern.inc P src/sys/dev/acpi/acpi_bat.c P src/sys/dev/mii/makphy.c P src/sys/dev/mii/makphyvar.h P src/sys/modules/ffs/Makefile P src/sys/modules/ufs/Makefile P src/sys/net/lagg/if_lagg_lacp.c P src/usr.sbin/cpuctl/arch/aarch64.c P src/usr.sbin/postinstall/postinstall.in Updating xsrc tree: Killing core files: Updating file list: -rw-rw-r-- 1 srcmastr netbsd 44096110 Jan 7 03:03 ls-lRA.gz
Re: execute statically-linked linux files
I forgot this:
---START PATCH---
--- sys/miscfs/procfs/procfs_vnops.c.orig 2021-12-09 04:11:22.778882692
+
+++ sys/miscfs/procfs/procfs_vnops.c2022-01-06 22:24:06.003672573 +
@@ -1400,6 +1400,7 @@
nc++;
}
if (error) {
+ procfs_proc_unlock(p);
ncookies = nc;
break;
}
@@ -1454,6 +1455,7 @@
nc++;
}
if (error) {
+ procfs_proc_unlock(p);
ncookies = nc;
break;
}
---END PATCH---
A couple of procfs_proc_unlock()s are missing in the
error path.
-RVP
Re: execute statically-linked linux files
On Thu, 6 Jan 2022, Manuel Bouyer wrote:
the second issue is that it expects /emul/linux/proc/self/fd/4 to be a working
symlink, and on NetBSD it's not. Note that with /bin/ls I get something
similar:
armandeche:/local/armandeche1/tmp#ktrace -i ls -l /proc/self/fd/
total 2
crw--w 1 bouyer tty5, 0 Jan 6 17:54 0
crw--w 1 bouyer tty5, 0 Jan 6 17:54 1
crw--w 1 bouyer tty5, 0 Jan 6 17:54 2
lr-xr-xr-x 1 rootwheel 2048 Jan 6 17:54 3 -> /local/armandeche1/tmp
ls: /proc/self/fd//4: Invalid argument
lr-xr-xr-x 1 rootwheel 0 Jan 6 17:54 4
22875 1 ls CALL readlink(0x7f7fffb98200,0x7f7fffb98610,0x400)
22875 1 ls NAMI "/proc/self/fd//4"
22875 1 ls RET readlink -1 errno 22 Invalid argument
If I can trust the ktrace output, fd/4 should point to /etc/spwd.db
On linux, strace shows it reading the link from /proc/self/exec, getting back
This 2nd issue I think I can explain: the fd existed at the start of a
readdir(), but, then is closed sometime when the listing is still in
progress as in the code below:
---
#include
#include
#include
#include
#include
#include
#include
#include
#include
int
main(void)
{
const char* const P = "/etc/passwd";
const char* const D = "/proc/self/fd";
struct dirent* d;
DIR* dir;
int fd, rc = EXIT_FAILURE;
if ((fd = open(P, O_RDONLY)) == -1)
err(rc, "open(%s)", P);
if ((dir = opendir(D)) == NULL)
err(rc, "opendir(%s)", D);
int count = 0;
while ((d = readdir(dir)) != NULL) {
char buf[PATH_MAX];
struct stat sb;
/* close before stat of P happens */
if (++count == 6) {
close(fd);
fd = -1;
}
snprintf(buf, sizeof buf, "%s/%s", D, d->d_name);
if (stat(buf, ) == -1) {
warn("stat(%s)", buf);
continue;
}
printf("%s: stat OK\n", buf);
}
closedir(dir);
close(fd);
rc = EXIT_SUCCESS;
return rc;
}
---
Not sure how to fix it though...
-RVP
Re: execute statically-linked linux files
On Thu, Jan 06, 2022 at 05:02:13PM +0100, Anders Magnusson wrote:
> Kave you looked at brandelf?
>
> https://www.freebsd.org/cgi/man.cgi?query=brandelf=1
Looks like what I need, thanks.
For the record, attached is my port to NetBSD of this
Interestingly, it seems to recognise all binaries as SVR4 (for NetBSD or
linux binaries) so it seems that the ELF type is recorded at some other place.
Anyway with a binary rebranded to linux I now hit another issue:
it quickly core dumps, with an issue that seems related to procfs:
with procfs only mounted on /emul/linux/proc, I get:
6369 6369 xc8 CALL open(0x43d6da,0x280800,0x66d208)
6369 6369 xc8 NAMI "/emul/linux/proc/self/exe"
6369 6369 xc8 NAMI "/proc/self/exe"
6369 6369 xc8 RET open -1 errno -2 No such file or directory
6369 6369 xc8 PSIG SIGSEGV SIG_DFL: code=SEGV_MAPERR, addr=0x0,
trap=14)
6369 6369 xc8 NAMI "xc8.core"
But /emul/linux/proc/self/exe should exists:
armandeche:/>ls -l /emul/linux/proc/self/exe
lr-xr-xr-x 1 root wheel 7 Jan 6 17:46 /emul/linux/proc/self/exe -> /bin/ls
armandeche:/>/emul/linux/bin/ls /emul/linux/proc/self/exe
/emul/linux/proc/self/exe
If I also mount procfs on /proc things go a bit further:
25735 25735 xc8 CALL open(0x43d6da,0x280800,0x66d208)
25735 25735 xc8 NAMI "/emul/linux/proc/self/exe"
25735 25735 xc8 NAMI "/proc/self/exe"
25735 25735 xc8 RET open 4
25735 25735 xc8 CALL readlink(0x7f7fd6f5,0x7f7fd830,0xfff)
25735 25735 xc8 NAMI "/emul/linux/proc/self/fd/4"
25735 25735 xc8 RET readlink -1 errno -22 Invalid argument
25735 25735 xc8 CALL close(4)
25735 25735 xc8 RET close 0
25735 25735 xc8 PSIG SIGSEGV SIG_DFL: code=SEGV_MAPERR, addr=0x0,
trap=14)
25735 25735 xc8 NAMI "xc8.core"
What's strange here is that /emul/linux/proc/self/exe should work as well
as /proc/self/exe
the second issue is that it expects /emul/linux/proc/self/fd/4 to be a working
symlink, and on NetBSD it's not. Note that with /bin/ls I get something
similar:
armandeche:/local/armandeche1/tmp#ktrace -i ls -l /proc/self/fd/
total 2
crw--w 1 bouyer tty5, 0 Jan 6 17:54 0
crw--w 1 bouyer tty5, 0 Jan 6 17:54 1
crw--w 1 bouyer tty5, 0 Jan 6 17:54 2
lr-xr-xr-x 1 rootwheel 2048 Jan 6 17:54 3 -> /local/armandeche1/tmp
ls: /proc/self/fd//4: Invalid argument
lr-xr-xr-x 1 rootwheel 0 Jan 6 17:54 4
22875 1 ls CALL readlink(0x7f7fffb98200,0x7f7fffb98610,0x400)
22875 1 ls NAMI "/proc/self/fd//4"
22875 1 ls RET readlink -1 errno 22 Invalid argument
If I can trust the ktrace output, fd/4 should point to /etc/spwd.db
On linux, strace shows it reading the link from /proc/self/exec, getting back
the executable path and doing a stat on it.
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
/*-
* SPDX-License-Identifier: BSD-3-Clause
*
* Copyright (c) 2000, 2001 David O'Brien
* Copyright (c) 1996 Søren Schmidt
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* 1. Redistributions of source code must retain the above copyright
*notice, this list of conditions and the following disclaimer
*in this position and unchanged.
* 2. Redistributions in binary form must reproduce the above copyright
*notice, this list of conditions and the following disclaimer in the
*documentation and/or other materials provided with the distribution.
* 3. The name of the author may not be used to endorse or promote products
*derived from this software without specific prior written permission
*
* THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR
* IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
* OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
* IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT,
* INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
* NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
* DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
* THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
* (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
* THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
*/
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
static int elftype(const char *);
static const char *iselftype(int);
static void printelftypes(void);
static void usage(void);
struct ELFtypes {
const char *str;
int value;
};
/* XXX - any more types? */
static struct ELFtypes elftypes[] = {
{ "FreeBSD", ELFOSABI_FREEBSD },
{ "NetBSD", ELFOSABI_NETBSD },
{
Re: execute statically-linked linux files
Kave you looked at brandelf? https://www.freebsd.org/cgi/man.cgi?query=brandelf=1 Den 2022-01-06 kl. 16:48, skrev Manuel Bouyer: Hello, I have linux binaires I'd like to run on NetBSD (this is a commercial product). Some files are dynamically-linked files and run properly. They show up as: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.24, BuildID[sha1]=38afca809a07f7e934012f7dac9094e3bcd2585d, stripped But there are also some statically-linked files, which shows up as ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, stripped (note the missing "for GNU/Linux" here) and NetBSD don't want to run them (Exec format error. Binary file not executable.). Is there a way to convert the ELF header so that NetBSD can run them ? thanks
execute statically-linked linux files
Hello, I have linux binaires I'd like to run on NetBSD (this is a commercial product). Some files are dynamically-linked files and run properly. They show up as: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.24, BuildID[sha1]=38afca809a07f7e934012f7dac9094e3bcd2585d, stripped But there are also some statically-linked files, which shows up as ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, stripped (note the missing "for GNU/Linux" here) and NetBSD don't want to run them (Exec format error. Binary file not executable.). Is there a way to convert the ELF header so that NetBSD can run them ? thanks -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
