4 ms·

Here is what: ls -l /proc/cpuinfo It says (basically it is a pseudo-filesystem with read-only permission, so I don't think so it is possible without maki

Here is what: ls -l /proc/cpuinfo It says (basically it is a pseudo-filesystem with read-only permission, so I don't think so it is possible without making any changes at the Linux kernel/driver level): -r--r--r-- 1 root root 0 Oct 28 09:38 /proc/cpuinfo

bravetraveler 4y ago
Indeed, the proc filesystem is well maintained by the kernel. I understand that part, less so if it's properly immutable/irreplaceable The thing is, it has to get the information from somewhere -- and depending on the age/type of the hardware (physical or virtualized), masking this is either easy or nearly impossible I remember changing this information (DMI?) was more common back in the like Pentium 3 era, for example.
- bravetraveler 4y ago
  Others have helped me understand this is part of the CPUID thing -- you know, the core of the topic for the overall post! I appreciate it everyone, save your fingers :) I've seen this done for physical chips before too, but I can't recall anything - hence vagueness
dezgeg 4y ago
I wonder if one could bind-mount some other proc file (say /proc/$EVIL_PID/cmdline) over cpuinfo to fake content. Would meet root and be visible in mount output though.
- stormbrew 4y ago
  You definitely can and things like that are precisely why bind mounts (usually) require root, because POSIX is built very much on the premise of one filesystem tree seen by both privileged and unprivileged users. Other systems do better by not depending on that.
- raimue 4y ago
  It would be easier to intercept the open() for the /proc/cpuinfo file with a LD_PRELOAD library. Of course that would still be detectable by the benchmark. You could also use a modified libc to spoof it. Then their only way out would be static linking. You could even just modify the kernel to report arbitrary strings in /proc/cpuinfo. So they use the CPUID instruction instead. The CPUID instruction can be trapped to throw a SIGSEGV instead of returning real values on x86 with arch_prctl(ARCH_SET_CPUID, 0). So an injected SIGSEGV handler could then spoof it. But even then, you could also trap the CPUID instruction in the kernel, and spoof it from there, which would be even harder to detect from user space. In the end, the benchmark program always needs to trust the kernel. Is it really worth trying to detect spoofing?

bravetraveler 4y ago

Indeed, the proc filesystem is well maintained by the kernel. I understand that part, less so if it's properly immutable/irreplaceable The thing is, it has to get the information from somewhere -- and depending on the age/type of the hardware (physical or virtualized), masking this is either easy or nearly impossible I remember changing this information (DMI?) was more common back in the like Pentium 3 era, for example.

bravetraveler 4y ago
Others have helped me understand this is part of the CPUID thing -- you know, the core of the topic for the overall post! I appreciate it everyone, save your fingers :) I've seen this done for physical chips before too, but I can't recall anything - hence vagueness

dezgeg 4y ago

I wonder if one could bind-mount some other proc file (say /proc/$EVIL_PID/cmdline) over cpuinfo to fake content. Would meet root and be visible in mount output though.

stormbrew 4y ago
You definitely can and things like that are precisely why bind mounts (usually) require root, because POSIX is built very much on the premise of one filesystem tree seen by both privileged and unprivileged users. Other systems do better by not depending on that.
raimue 4y ago
It would be easier to intercept the open() for the /proc/cpuinfo file with a LD_PRELOAD library. Of course that would still be detectable by the benchmark. You could also use a modified libc to spoof it. Then their only way out would be static linking. You could even just modify the kernel to report arbitrary strings in /proc/cpuinfo. So they use the CPUID instruction instead. The CPUID instruction can be trapped to throw a SIGSEGV instead of returning real values on x86 with arch_prctl(ARCH_SET_CPUID, 0). So an injected SIGSEGV handler could then spoof it. But even then, you could also trap the CPUID instruction in the kernel, and spoof it from there, which would be even harder to detect from user space. In the end, the benchmark program always needs to trust the kernel. Is it really worth trying to detect spoofing?