Orange Pi PC: /usr/bin/su is a x86-64 binary

[AlexaDP]

I just discovered that /usr/bin/su in my Armbian:

 

 v26.2.1 for Orange Pi PC running Armbian Linux 6.12.58-current-sunxi
 

is a x86_64 binary:

 

$ ls -l /usr/bin/su
-rwsr-xr-x 1 root root 50800 Mar  6 13:10 /usr/bin/su

 

$ file /usr/bin/su
/usr/bin/su: setuid ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, no section header
 

I installed the rust version, su-rs, but I thought it would be useful to warn about this. 

 

I checked /usr/bin and /usr/sbin and this is the only x86-64 executable.

Edited 18 hours ago by AlexaDP

[bedna]

Yes, applications are compiled into binaries, su is not a script.

 

This is on for example Arch:

$ file $(which su)

/usr/bin/su: setuid ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=d47af40eeb87fea42d555df0d1385bc9a4b4df2c, for GNU/Linux 4.4.0, stripped

 

Quote

I installed the rust version, su-rs, but I thought it would be useful to warn about this. 

 

Ok? So it's compiled with rust instead of C, still a binary.

 

Quote

I checked /usr/bin and /usr/sbin and this is the only x86-64 executable.

 

I find that extremely hard impossible to believe.

 

https://www.reddit.com/r/learnprogramming/comments/lyw9gf/can_someone_explain_what_people_mean_by_binaries

Edited 11 hours ago by bedna

[AlexaDP]

Bedna

 

I know that su  command is a compiled binary but Orange Pi PC has a 32 bit ARM processor and not a 64 bit Intel (x86_64) processor.

 

I find that extremely hard and impossible to believe that you missed the point.

Edited 8 hours ago by AlexaDP

[Werner]

If this is really the case, then this must be an upstream issue since Armbian does not touch this file AFAIK.

 

Picked a random userspace from armhf (since you did not state which you are using)

 

~/build/cache/rootfs/bin# file su
su: setuid ELF 32-bit LSB pie executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-armhf.so.3, BuildID[sha1]=b24ceef58082e181650b17e52819559be2d3a97b, for GNU/Linux 3.2.0, stripped

 

[bedna]

It's ARMv7 so it could potentially run 64bit instructions.

 

https://developer.arm.com/documentation/den0013/0400/Introduction-to-Assembly-Language/The-ARM-instruction-sets

Quote

The ARMv7 architecture is a 32-bit processor architecture. It is also a load/store architecture, meaning that data-processing instructions operate only on values in general purpose registers. Only load and store instructions access memory. General purpose registers are also 32 bits. Throughout this book, when we refer to a word, we mean 32 bits. A doubleword is therefore 64 bits and a halfword is 16 bits wide.

Though the ARMv7 architecture is a 32-bit architecture, individual processor implementations do not necessarily have 32-bit width for all blocks and interconnections. For example, it is possible to have 64-bit, or wider paths for instruction fetches or data accesses.

 

I recall reading that opi pc is running 64-bit from someone here on armbian forums now that I think about it, but don't remember where.

It could also be a Mandela effect and I am completely wrong.

If so, I'm sorry, did not mean to make you upset.

 

8 hours ago, AlexaDP said:

I find that extremely hard and impossible to believe that you missed the point.

 

Not hard to miss at all, or you think everybody has every single board memorized? 😉

If you included that you think it should run 32 bit instructions and has a 32bit kernel, I would have asked you to provide "uname -m" to confirm, no need to be nasty. 🙃

Kinda strange that you could get the system running with su in 64bit with a 32bit kernel though.