GNU bug report logs - #43668
Daemon tries to build GNU/Hurd derivations on GNU/Linux

Previous Next

Full log

Message #8 received at 43668 <at> debbugs.gnu.org (full text, mbox):

From: Ludovic Courtès <ludo <at> gnu.org>
To: 43668 <at> debbugs.gnu.org
Subject: Re: bug#43668: Daemon tries to build GNU/Hurd derivations on GNU/Linux
Date: Mon, 28 Sep 2020 12:31:22 +0200

[Message part 1 (text/plain, inline)]

Ludovic Courtès <ludo <at> gnu.org> skribis:

> It’s no wonder that the GNU/Hurd executable fails to run on GNU/Linux.
> The reason the daemon tries to run it anyway is because of the hack
> introduced in 7bf2a70a4ffd976d50638d3b9f2ec409763157df, in support of
> transparent emulation via binfmt_misc.

The thing is that x86 GNU/Hurd and GNU/Linux ELF binaries are
indistinguishable AFAICS since they both use ELFOSABI_NONE:

--8<---------------cut here---------------start------------->8---
scheme@(guile-user)> ,use(guix elf)
scheme@(guile-user)> ,use(rnrs io ports)
scheme@(guile-user)> (define e (parse-elf (call-with-input-file "/gnu/store/vq7zyb4hmlrafflmrcjbqccxp4dsx0s3-bash" get-bytevector-all)))
scheme@(guile-user)> (elf-abi e)
$6 = 0
scheme@(guile-user)> ELFOSABI_GNU
$7 = 3
scheme@(guile-user)> (define e2 (parse-elf (call-with-input-file "/bin/sh" get-bytevector-all)))
scheme@(guile-user)> (elf-abi e2)
$8 = 0
--8<---------------cut here---------------end--------------->8---

(The ‘file’ command does manage to recognize GNU/Hurd binaries, but I
don’t know how it does it.)

So I think we can’t count on an ‘execve’ error and thus have to treat
this case (same architecture but different OS kernel) specially, as
shown below.

Thoughts?

Ludo’.

[Message part 2 (text/x-patch, inline)]

diff --git a/nix/libstore/build.cc b/nix/libstore/build.cc
index 88f8d11103..ccec513d8d 100644
--- a/nix/libstore/build.cc
+++ b/nix/libstore/build.cc
@@ -1946,6 +1946,15 @@ void DerivationGoal::startBuilder()
 
 }
 
+/* Return true if the operating system kernel part of SYSTEM1 and SYSTEM2 (the
+   bit that comes after the hyphen in system types such as "i686-linux") is
+   the same.  */
+static bool sameOperatingSystemKernel(const std::string& system1, const std::string& system2)
+{
+    auto os1 = system1.substr(system1.find("-"));
+    auto os2 = system2.substr(system2.find("-"));
+    return os1 == os2;
+}
 
 void DerivationGoal::runChild()
 {
@@ -2208,9 +2217,20 @@ void DerivationGoal::runChild()
         foreach (Strings::iterator, i, drv.args)
             args.push_back(rewriteHashes(*i, rewritesToTmp));
 
-        execve(drv.builder.c_str(), stringsToCharPtrs(args).data(), stringsToCharPtrs(envStrs).data());
-
-	int error = errno;
+	/* If DRV targets the same operating system kernel, try to execute it:
+	   there might be binfmt_misc set up for user-land emulation of other
+	   architectures.  However, if it targets a different operating
+	   system--e.g., "i586-gnu" vs. "x86_64-linux"--do not try executing
+	   it: the ELF file for that OS is likely indistinguishable from a
+	   native ELF binary and it would just crash at run time.  */
+	int error;
+	if (sameOperatingSystemKernel(drv.platform, settings.thisSystem)) {
+	    execve(drv.builder.c_str(), stringsToCharPtrs(args).data(),
+		   stringsToCharPtrs(envStrs).data());
+	    error = errno;
+	} else {
+	    error = ENOEXEC;
+	}
 
 	/* Right platform?  Check this after we've tried 'execve' to allow for
 	   transparent emulation of different platforms with binfmt_misc

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.