Using intel's sde to chroot into a ROOT.

[dE_logics]

I'm trying to chroot into an x86-64 (built using -march=icelake-client) system from another x86-64 system who's CPU has incompatible instructions to icelake-client (znver1). The incompatibility is avx512 -- even qemu softmmu has not implemented it, so I'm using Intel's SDE which IS able to execute these binaries at least.

However I'm not able to chroot using it to the this ROOT. I copied over the SDE (which is a directory) to ROOT and --

Code: Select all

chroot /usr/x86_64-mypl-linux-gnu/ /sde64 -- /bin/bash

However I'm getting --

Code: Select all

traps: sde64[229146] trap invalid opcode ip:7f56db09475d sp:7ffd55266fa8 error:0 in ld-linux-x86-64.so.2[1e75d,7f56db077000+2c000]

So the ROOT's ld-linux-x86-64.so.2 is being used to execute sde64; also sde64 links against libc. So what I did is copied the host's libc.so.6 and ld-linux-x86-64.so.2 to /znver1/ of ROOT and --

Code: Select all

chroot /usr/x86_64-mypl-linux-gnu/ /znver1/ld-linux-x86-64.so.2 --library-path /znver1/ ./sde64 -icl -- /bin/bash

which AGAIN results in

Code: Select all

Illegal instruction (core dumped)

Code: Select all

traps: pinbin[229213] trap invalid opcode ip:7f92d3d3775d sp:7fffca461648 error:0 in ld-linux-x86-64.so.2[1e75d,7f92d3d1a000+2c000]

Interestingly the sde64 binary itself works. For e.g --help works.

I tried the other way round by executing chroot using sde64 --

Code: Select all

./sde64 -icl -- /usr/bin/chroot /usr/x86_64-mypl-linux-gnu/

Here it sde64 executable exits and chroot just hangs. It has to be SIGKILLed.

I also tried to convert sde64 to static binaries and it did not help.

[Administrator note: this appears to follow from the qemu thread Determining unsupported instructions in qemu softmmu. -Hu]

[dE_logics]

This 'Intel SDE' is propitiatory garbage.

Code: Select all

E: Fork for injector launcher failed: Out of memory

It can only be used for 'hello world' type programs.

[NeddySeagoon]

dE_logics,

I tried the other way round by executing chroot using sde64 --
Code:
./sde64 -icl -- /usr/bin/chroot /usr/x86_64-mypl-linux-gnu/


Here it sde64 executable exits and chroot just hangs. It has to be SIGKILLed.

The chroot leaves the sde64 dir outside of the chroot so that it can't load any more of itself.

It's Intel software, designed to emulate newer Intel CPU instructions, probably only on older Intel CPUs.
znver1 sounds a lot like AMD. I would not be surprised if it failed with AMD instructions involved either on the host or target.

I've not had an Intel CPU since my 32 bit Atom in an Acer One netbook, so I can't test here.

[dE_logics]

But AMD is supposed to have extra instructions which Intel never incorporated. So that shouldn't be a problem. Also sde binary must be built with x86-64 baseline instruction set so it must run on even the 2003 era Athlon processors, but this zen. So it shouldn't be a problem.

So what I'll do is put the chroot dir in the sde64 dir (--bind mount).

[Ralphred]

but this zen. So it shouldn't be a problem.

Zen has some "missing" instructions compared to Bulldozer, I'was bitten by it first 8 or so years ago during a "hardware upgrade", and avoided it recently again: Doing an emerge -e world on new hardware is always kinda cool, but having to do it before the hardware upgrade just sucks

[dE_logics]

but this zen. So it shouldn't be a problem.

Zen has some "missing" instructions compared to Bulldozer, I'was bitten by it first 8 or so years ago during a "hardware upgrade", and avoided it recently again: Doing an emerge -e world on new hardware is always kinda cool, but having to do it before the hardware upgrade just sucks

But still there's no chance of Intel's SDE using those instructions. The machine I'm trying to chroot into us icelake.

[dE_logics]

But AMD is supposed to have extra instructions which Intel never incorporated. So that shouldn't be a problem. Also sde binary must be built with x86-64 baseline instruction set so it must run on even the 2003 era Athlon processors, but this zen. So it shouldn't be a problem.

So what I'll do is put the chroot dir in the sde64 dir (--bind mount).

I put the chroot dir into the SDE's directory and still hanged.

Do you have any other suggessions. Would placing the sde dir's contents into the ROOT of the chroot dir help?

[NeddySeagoon]

dE_logics,

The SDE must be available inside the chroot, or the chroot will leave the SDE outside the chroot and therefore inaccessible.
Putting SDE in your path, when you want to chroot is tricky as it will either be wrong inside or outside the chroot.

I'm surprised that you only pass ./SDE, a directory and not some binary program name within ./SDE, which effectively treats the program after the -- as data. Much as qemu does.

[dE_logics]

I'll try it out. But still a better approach will be to make the kernel execute the emulator when it detects that the executable lies in a certain matching path (like /tmp/portage). That way cross compiling bugs can be overcome and it'll still be reasonably fast.

I found update-binfmts --detector. This may work?

[dE_logics]

dE_logics,

The SDE must be available inside the chroot, or the chroot will leave the SDE outside the chroot and therefore inaccessible.
Putting SDE in your path, when you want to chroot is tricky as it will either be wrong inside or outside the chroot.

I'm surprised that you only pass ./SDE, a directory and not some binary program name within ./SDE, which effectively treats the program after the -- as data. Much as qemu does.

IT WORKED!! It to copy all SDE's 'innards' to / and also to /usr/x86_64-mypl-linux-gnu//usr/x86_64-mypl-linux-gnu/

Thanks for helping with all that experience Neddy!!