@dezgeg, thanks for your PR! By analyzing the history of the files in this pull request, we identified @Ericson2314, @errge and @edolstra to be potential reviewers.

I was playing with a similar solution last week (https://github.com/expipiplus1/nixpkgs/blob/17c8652edbe164457e763d37cdaea03cd7251f91/pkgs/tools/misc/coreutils/uname-armv7l.patch) and discovered that (annoyingly) some packages use a system call to determine that machine instead of calling uname, the go 1.4 compiler is an example.

@grahamc @bennofs mused if it would be possible to use some systemtap magic to intercept the system call

@bennofs has suggested overriding the uname function in libc by using LD_PRELOAD

Edit, I misremembered who mentioned systemtap

I'm not really in favor of this. It seems a bit hacky and adds considerable complexity to stdenv. (E.g. you have to be careful to ensure that fake-uname appears before coreutils' uname.)

An alternative would be to patch coreutils' uname to return a deterministic value based on some environment variable (say NIX_UNAME=<sysname>:<machine>:...). Also hacky but it would probably be just a few lines of code and wouldn't require duplicating all of uname's argument parsing. It wouldn't fix the uname() syscall, but please let's not do global LD_PRELOAD hacks or (shudder) systemtap magic just for go.

(Actually the environment variable hack could also be done in Glibc's uname(). Then it would work for everything except direct syscalls.)

The glibc idea sounds good, I will give that a shot...

Apparently that's not easy, as glibc build just auto-generates some wrappers from a system call list instead of having uname() written in C code...

Oh, too bad :-(

@dezgeg perhaps you can remove uname from the "list of auto-generated stuff" and add it manually?

That seems too complex and risky for very little gain. For Go you can set GOHOSTARCH, GOARCH and GOARM manually anyway to avoid the autodetection. And in fact you really have to set them to avoid impurities because the build system also tries to execute various floating point instructions and checks if a SIGILL was raised or not...

Coreutils seems a better place to hack.

I'd blacklist the system call itself at build time for sandboxed builds. Autodetection during configuration is rarely a good idea, period. Go wouldn't use glibc to do the system call anyways, would it?

At least in the bootstrap Go uname is called only in shell scripts and some C code.

Not sure if blacklisting is a good idea, but we could use @aszlig's seccomp patch for Nix to make the uname syscall return a different value. This would compensate for the lack of a personality() for ARMv6.

If I remember correctly, besides optionally killing the process seccomp BPF filters can only affect the return value of a system call, not any values in userspace memory.

@dezgeg: Well, you can via SECCOMP_RET_TRAP and SECCOMP_RET_TRACE, but that will be complicated as well, is very architecture specific and isn't supported by libseccomp.

For example this was my WIP handler for rewriting the stat-family of syscalls:

void rewriteStatHandler(int signo, siginfo_t *si, void *ctx) {
    ucontext_t *uc = reinterpret_cast<ucontext_t*>(ctx);

    if (signo != SIGSYS || si->si_code != SYS_SECCOMP || !uc)
        throw SysError("unexpected SIGSYS triggered");

    if (si->si_arch == SCMP_ARCH_X86_64) {
        long ret = syscall(si->si_syscall,
                           uc->uc_mcontext.gregs[REG_RDI],
                           uc->uc_mcontext.gregs[REG_RSI]);
        uc->uc_mcontext.gregs[REG_RAX] = ret;
        if (ret != 0) return;
        struct stat st;
        memcpy(&st, &uc->uc_mcontext.gregs[REG_RSI], sizeof(st));
        st.st_uid = 0;
        st.st_gid = 0;
        uc->uc_mcontext.gregs[REG_RSI] = reinterpret_cast<greg_t>(&st);
    }
}

So you can change any register with this, but because you're working on register-level you're also highly architecture dependant.

Another reason why it's probably not a good idea is that seccomp also comes with a bit of overhead.

By "blacklisting" I mean just fail the build. If killing the process is also easier / more performant, all the better!

On darwin it would be really nice to have a fake sw_vers. In my experience, missing it was leading to much build breakage.

We actually have a real sw_vers in Darwin.DarwinTools but a fake one might be useful too.

Are there any updates on this pull request, please?

Thank you for your contributions.
This has been automatically marked as stale because it has had no activity for 180 days.
If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity.
Here are suggestions that might help resolve this more quickly:

1. Search for maintainers and people that previously touched the
   related code and @ mention them in a comment.
2. Ask on the NixOS Discourse. 3. Ask on the #nixos channel on
   irc.freenode.net.

There is this patch from Ubuntu folks and it works great: https://lists.ubuntu.com/archives/kernel-team/2016-January/068203.html

{ config, pkgs, ... }:
{
  boot.kernelPatches = [
    rec {
      name = "compat_uts_machine";
      patch = pkgs.fetchpatch {
        inherit name;
        url = "https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/jammy/patch/?id=c1da50fa6eddad313360249cadcd4905ac9f82ea";
        sha256 = "sha256-mpq4YLhobWGs+TRKjIjoe5uDiYLVlimqWUCBGFH/zzU=";
      };
    }
  ];
  boot.kernelParams = [
    "compat_uts_machine=armv7l"
  ];
}

[misuzu@oracle:~]$ uname -m
aarch64
[misuzu@oracle:~]$ linux32
[misuzu@oracle:~]$ uname -m
armv7l

Is it still relevant?

This PR seems stalled. Closing.

A deterministic uname was finally added in #210102